4、硬件信任根：eFuse与OTP原理、硬件唯一密钥（HUK）的生成与保护、物理不可克隆函数（PUF）简介

各位同学，咱们今天聊点硬核的——硬件信任根。说白了，就是整个安全体系的“祖坟”。你想想看，软件层面的安全再怎么加固，如果硬件本身就不靠谱，那一切等于白搭。我这些年做TEE部署，踩过最大的坑，十有八九都跟硬件信任根没搞扎实有关。

先说说eFuse和OTP。这俩东西，本质上都是“一次性可编程存储器”。

OTP（One-Time Programmable），顾名思义，只能写一次。写进去之后，就再也改不了了。这就像在石头上刻字，刻完就定型了。

eFuse 是OTP的一种具体实现。它利用电迁移效应，通过大电流“熔断”芯片内部的金属丝或多晶硅丝。熔断前代表“0”，熔断后代表“1”。一旦熔断，不可恢复。

我在项目中遇到过一件事：某次产线烧录，因为电压不稳定，导致一批芯片的eFuse烧录了一半就停了。结果这批芯片既不是全0，也不是全1，处于一种“半熔断”的诡异状态。嗯，那批货最后全废了。所以，烧录eFuse时，电源稳定性是第一位的。

⚠️ 警告： eFuse烧录是不可逆操作。一旦烧错，芯片直接报废。建议在烧录前做三次校验，确保数据无误。

eFuse在TEE里主要用来存什么？

这里有个关键点：eFuse的容量通常很小，几十到几百个bit。所以，我们不会把完整的密钥存进去，而是存一个“种子”，再由这个种子派生出其他密钥。

HUK，全称Hardware Unique Key。每颗芯片出厂时，都会基于eFuse中存储的种子，结合芯片自身的物理特性，生成一个独一无二的密钥。

这个密钥有什么用？

HUK的生成过程，我习惯这么设计：

HUK = KDF(HUK_Seed || Chip_ID || Die_Coordinate)

其中：

这样生成的HUK，即使两个芯片的eFuse种子相同（理论上概率极低），最终的HUK也会因为物理坐标不同而不同。

💡 提示： HUK必须永远不出TEE。它只能在TEE内部使用，任何试图将HUK读出到REE（富执行环境）的操作，都应该被硬件阻止。我曾经见过一个方案，把HUK通过MMIO寄存器暴露给REE，结果被侧信道攻击一把梭了。

PUF，Physical Unclonable Function。这玩意儿很有意思，它利用芯片制造过程中不可避免的工艺偏差，来生成一个独一无二的“指纹”。

你想想看，同一片晶圆上，不同位置的晶体管，阈值电压、延迟时间都会有微小的差异。这些差异，就是PUF的“熵源”。

PUF和eFuse最大的区别是什么？

PUF的典型应用场景：

不过，PUF也有它的毛病。最典型的就是噪声问题。同一个PUF，在不同温度下读出来的响应可能不一样。所以，PUF输出后面必须跟一个纠错电路（ECC），把有噪声的响应纠正成稳定的密钥。

我个人习惯，在量产时会把PUF的辅助数据（Helper Data）存到eFuse里。这样，每次上电时，PUF + Helper Data + ECC，就能稳定地恢复出同一个密钥。

  🔑 核心要点： eFuse是“写进去就固定”，PUF是“读出来才生成”。两者结合，可以构建出既稳定又抗物理攻击的硬件信任根。

下面这张图，是我自己梳理的硬件信任根知识体系。你可以把它当作一个“地图”，方便理解各个组件之间的关系。

这张图里，我把eFuse、HUK、PUF的关系梳理得很清楚。说白了，eFuse是“地基”，HUK是“房子”，PUF是“防盗门”。三者缺一不可。

最后，分享几个我亲身踩过的坑：

eFuse烧录时序：不同厂家的eFuse，烧录时序差异很大。有的需要先擦除再写入，有的直接写就行。一定要仔细看Datasheet，别想当然。
HUK派生不要用固定盐：有些方案为了省事，直接用全0作为盐。这等于把HUK的熵源砍掉了一半。我建议用芯片ID + 随机数作为盐。
PUF的纠错开销：PUF的纠错电路不是免费的。它需要额外的存储空间存Helper Data，还需要额外的计算时间。量产前一定要评估好成本和性能。
测试覆盖率：eFuse和PUF在芯片测试阶段，必须100%覆盖。我见过一个项目，因为测试向量没覆盖到某个eFuse位，导致量产时1%的芯片无法正常启动。

嗯，硬件信任根这块，内容确实不少。但只要你把eFuse、HUK、PUF这三者的关系理清了，后面的安全启动、安全存储，都会顺理成章。