📚 课程目录第2章安全芯片与硬件信任根

2、安全芯片与硬件信任根：安全元件(SE)选型、安全密钥存储、硬件唯一密钥(DUK)管理

Matter 设备的安全，说白了就是密钥的安全。你想想看，设备入网靠的是 DAC 证书，通信靠的是 CASE 会话密钥，固件升级靠的是 CD 签名——这些环节只要有一个密钥泄露，整个信任链就断了。

我做了这么多年物联网安全，见过太多「软件加密」翻车的案例。有人把私钥藏在 Flash 的某个角落，结果被 JTAG 读出来；有人用 MCU 内置的 OTP 存密钥，结果被侧信道攻击破解。嗯，所以 Matter 强制要求：密钥必须由硬件安全元件保护。

2.1 安全元件选型：不是越贵越好

选 SE 芯片，我个人的习惯是先看三样东西：安全等级认证、存储容量、接口兼容性。

评估维度	关键指标	我的建议
安全认证	CC EAL4+ / FIPS 140-2 Level 2+	至少 EAL4+，Matter 认证要求
密钥存储	非易失性存储 ≥ 32KB	够放 DAC + 多组 DUK + 固件密钥
接口	I²C / SPI / SWI	I²C 最常用，注意电平匹配
功耗	待机 ≤ 1μA	电池设备必须考虑
成本	批量价 0.3~1.5 USD	别为了省钱选无认证的

⚠️ 避坑指南： 我曾经遇到一个客户，选了某款便宜 SE，结果发现它不支持 Matter 要求的 P256 曲线加速。每次签名要 800ms，设备入网时直接超时。所以选型前一定要确认：硬件是否支持 ECDSA 和 ECDH 硬件加速。

2.2 安全密钥存储：密钥不能「裸奔」

密钥存储的核心原则就一句话：密钥永远不应该以明文形式出现在 MCU 的 RAM 或 Flash 中。

Matter 设备涉及以下几类密钥：

DAC 私钥：设备认证证书的私钥，出厂预置，终身不变
DUK（Device Unique Key）：硬件唯一密钥，用于派生会话密钥
固件签名公钥：验证 OTA 固件签名，通常存储在 SE 的只读区
ICAC / PAA 证书：用于验证证书链，可存于外部 Flash（只读）

我建议的存储方案是这样的：

┌─────────────────────────────────────────┐
│           安全元件 (SE)                    │
│  ┌─────────────┐  ┌──────────────────┐  │
│  │ DAC 私钥     │  │ DUK (唯一密钥)    │  │
│  │ (不可导出)   │  │ (不可导出)        │  │
│  └─────────────┘  └──────────────────┘  │
│  ┌─────────────┐  ┌──────────────────┐  │
│  │ 固件公钥     │  │ 会话密钥缓存      │  │
│  │ (只读)       │  │ (临时)           │  │
│  └─────────────┘  └──────────────────┘  │
└─────────────────────────────────────────┘
         ▲                    ▲
         │ I²C/SPI           │
         ▼                    ▼
┌─────────────────────────────────────────┐
│           主控 MCU                        │
│  ┌──────────────────────────────────┐   │
│  │ 证书链 (DAC/ICAC/PAA)            │   │
│  │ 存储于外部 Flash (可读不可写)     │   │
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘

💡 个人经验： 我习惯在 SE 内部划一个「密钥槽位表」，每个槽位有 ID、类型、访问权限。这样固件升级时，新固件只能读取「固件公钥」槽位，永远碰不到 DAC 私钥槽位。

2.3 硬件唯一密钥(DUK)管理

DUK 是 Matter 设备安全的核心。每个设备出厂时，SE 内部会生成一个唯一的 256 位密钥。这个密钥有两个特点：

唯一性：全球没有两个设备拥有相同的 DUK
不可导出：SE 只提供「用 DUK 做运算」的接口，不提供「读出 DUK」的接口

DUK 的主要用途是派生各种会话密钥。举个例子：

// 伪代码：使用 DUK 派生 CASE 会话密钥
// 输入：DUK (存储在 SE 内部)
// 输入：随机数 random1, random2 (来自对端设备)
// 输出：会话密钥 session_key

function derive_session_key(random1, random2):
    // 1. 拼接随机数
    input = random1 || random2
    
    // 2. 调用 SE 的 HKDF 扩展指令
    //    注意：DUK 永远不会离开 SE
    session_key = SE.HKDF_expand(
        key_slot = DUK_SLOT_ID,  // 引用 DUK 槽位
        input    = input,
        length   = 16            // AES-128 密钥长度
    )
    
    return session_key

    🔑 关键点： DUK 的派生过程全部在 SE 内部完成。MCU 只能拿到派生后的会话密钥，永远接触不到 DUK 本身。这就是硬件信任根的威力——即使 MCU 被攻破，攻击者也拿不到设备的长期密钥。

2.4 DUK 生命周期管理

DUK 从生成到销毁，每个阶段都有讲究。我整理了一个生命周期表：

阶段	操作	安全要求
生成	SE 内部 TRNG 生成 256 位随机数	必须在安全制造环境进行
存储	写入 SE 的 OTP 或 eFuse 区域	一次性写入，不可修改
使用	通过 SE 指令进行派生/签名	每次操作需鉴权（如 PIN 或 MAC）
备份	仅在安全 HSM 中备份	备份密钥与设备分离存储
销毁	SE 自毁指令或物理销毁	确保无法恢复

⚠️ 我曾经踩过的坑： 有次量产时，工厂把 DUK 生成脚本写错了，导致一批设备的 DUK 全部相同。结果这些设备入网时互相冲突，Matter 控制器认为它们在重放攻击。最后只能全部返工。所以 DUK 生成后，一定要在产线做唯一性校验。

2.5 安全芯片与 MCU 的通信保护

SE 和 MCU 之间的通信通道，其实是最容易被忽略的攻击面。你想想看，如果 I²C 总线上的数据是明文的，攻击者用逻辑分析仪就能抓到会话密钥。

我建议的做法是：

启用 SE 的安全通道协议：大部分 SE 支持 SCP（Secure Channel Protocol），通信前先做双向认证
每条指令加 MAC：防止重放攻击
物理隔离：SE 的 I²C 走独立总线，不要和传感器共用

// 安全通道建立流程（简化版）
1. MCU 发送随机数 challenge 给 SE
2. SE 用 DUK 对 challenge 签名，返回签名值
3. MCU 验证签名（使用 SE 的公钥证书）
4. 双方派生会话加密密钥
5. 后续所有通信使用 AES-CCM 加密

💡 我的习惯： 即使 SE 支持安全通道，我仍然会在 PCB 布局上把 SE 的通信引脚用 GND 包围起来，减少侧信道泄露的风险。安全设计要「层层设防」。

2.6 知识体系总览

下面这张图总结了本章的核心逻辑：

这张图把本章的知识点串起来了。从 SE 选型开始，到密钥存储、DUK 管理、通信保护，最终落到「硬件信任根」这个核心概念上。你设计 Matter 设备时，可以拿这张图当 checklist，看看每个环节是否都覆盖到了。