2、硬件信任根：MTK8676内部ROM代码、一次性可编程存储器(OTP/eFuse)、物理不可克隆函数(PUF)
各位同学，咱们今天聊点硬核的——硬件信任根。说白了，这就是整个安全体系的“地基”。你想想看，如果地基都不牢，上面盖再高的楼也没用。在车规级座舱芯片里，MTK8676的信任根设计，我个人觉得是做得相当扎实的。
2.1 内部ROM代码：不可篡改的“第一行代码”
芯片上电后，CPU执行的第一条指令从哪里来？没错，就是从内部ROM里来。这个ROM是芯片出厂时一次性烧录好的，物理上无法修改。我习惯把它叫做“硅前固化代码”。
为什么一定要用ROM？因为它是只读的。任何外部攻击者，哪怕你把芯片泡在酸里，用电子显微镜看，也改不了ROM里的内容。这就是信任的起点。
核心作用：ROM代码负责验证下一级Bootloader的签名。如果签名不对，芯片直接死循环或者进入安全错误状态。这就是“信任链”的第一环。
我在项目中遇到过一件事：有次调试一块板子，死活起不来。查了半天，发现是Bootloader的签名算法版本和ROM里固化的验签算法不匹配。嗯，这种坑踩过一次就记住了。所以大家做开发时，一定要确认ROM固件的验签算法版本，别想当然。
2.2 OTP/eFuse：一次性可编程存储器的“熔丝哲学”
OTP，全称是One-Time Programmable。eFuse是其中一种实现方式，原理就像烧断一根保险丝。烧断了，就再也接不回去了。这个特性，用来存什么？
- 根密钥的哈希值：真正的根密钥可能很大，但OTP里只存它的SHA256摘要。用来验证ROM代码的签名。
- 芯片唯一ID：每颗芯片出厂时烧录一个全球唯一的ID，用于设备身份认证。
- 安全配置位：比如“是否强制开启安全启动”、“是否允许JTAG调试”等。这些位一旦烧了，就再也不能改。
重要警告：OTP烧录是不可逆的！我曾经见过一个同事，在调试阶段不小心把“禁止JTAG”的位给烧了。结果芯片再也连不上调试器，整块板子直接报废。所以，量产前一定要反复确认OTP的烧录脚本，最好加个“烧录确认”的二次弹窗。
MTK8676的OTP容量有多大？我印象中大概有几千比特。但别觉得多，真正用起来你会发现，每一比特都很珍贵。你想想看，要存公钥哈希、设备ID、各种配置位，很快就用完了。所以设计时要精打细算。
2.3 PUF：物理不可克隆函数的“芯片指纹”
PUF这个概念，说实话，我第一次接触时也觉得挺玄乎。它利用芯片制造过程中不可避免的工艺偏差——比如晶体管的阈值电压差异、金属线的延迟差异——来生成一个唯一的、不可预测的“指纹”。
为什么叫“不可克隆”？因为即使你拿到同一张光罩，同一套工艺参数，造出来的两颗芯片，它们的PUF值也完全不同。这就好比人的指纹，天生唯一。
实用技巧：PUF最常见的用法是生成密钥。芯片上电后，PUF模块读取物理特征，通过纠错码（比如模糊提取器）生成一个稳定的256位密钥。这个密钥不需要存储在OTP或Flash里，用的时候即时生成，用完就消失。攻击者即使物理剖片，也拿不到密钥。
MTK8676内部集成了PUF模块。我个人建议，如果你的产品对防物理攻击要求很高（比如车规级T-Box、网关），一定要用PUF。它比把密钥明文存到Flash里安全太多了。
不过PUF也有坑。我记得有一次，温度从-40°C变到85°C，PUF生成的密钥居然有几位翻转了。还好有纠错码兜底，不然整个安全体系就崩了。所以，PUF的纠错码设计一定要覆盖全温度范围，别偷懒。
2.4 三者如何协同工作？
咱们把这三个东西串起来，看看完整的信任链是怎么建立的：
- 上电复位：CPU从内部ROM开始执行代码。
- ROM代码读取OTP：从OTP里读出根密钥的哈希值，以及安全配置位。
- ROM代码调用PUF：PUF生成一个临时密钥，用于解密后续的Bootloader镜像（如果镜像加密的话）。
- ROM代码验签：用OTP里的根密钥哈希，验证Bootloader的签名。通过则跳转，不通过则死锁。
你看，ROM是“执行者”，OTP是“存储者”，PUF是“生成者”。三者缺一不可。
一句话总结：硬件信任根，就是ROM里不可改的代码 + OTP里不可逆的配置 + PUF里不可克隆的密钥。这三者构成了车规级安全启动的“铁三角”。
好了，这一节就到这里。下一节咱们聊聊Bootloader的签名验证流程，那里面有很多工程细节，比如签名算法选RSA还是ECDSA，哈希用SHA256还是SHA384。到时候我会分享一些实际项目中的选型经验。
课后思考：如果攻击者通过激光注入，改变了ROM代码的执行流，跳过验签步骤，你觉得OTP和PUF还能保护系统吗？欢迎在评论区讨论。
公众号:蓝海资料掘金营，微信deep3321