如果把“Chiplet”和“LLM”两个词放到同一张工作台上很多人的第一反应是一个在讲芯片封装和异构集成一个在讲大语言模型工具两者为什么要放到一起讨论安全这两件事正好同时发生让硬件安全从“芯片内部的事”变成了“整个产业链和算法生态的事”。Chiplet 把一颗 SoC 拆散成多颗来自不同供应商、不同工艺节点的 die再用 UCIe 这类接口拼装在一起LLM 则把硬件设计的自动化水平同时拉高——它既能自动生成 RTL、验证代码、安全断言也能被用来做攻击面分析、恶意代码生成和漏洞挖掘。设计门槛在降低攻击门槛也在降低但信任边界却变得更碎片化。这篇文章不绑定具体型号和产线而是把“硬件设计 安全 Chiplet LLM”四个关键词放在同一套逻辑里先讲清架构变化带来哪些新的安全边界再给出威胁模型与防护思路最后落到设计流程里怎么把安全验证和 LLM 辅助工具用起来。适合芯片设计工程师、EDA 与安全研究员、后端系统架构师以及所有关心硬件可信根的开发者和安全运维人员阅读。1. 主题速览维度说明文章主题Chiplet 与 LLM 时代的硬件设计安全核心变化芯片从单片 SoC 转向异构多 die 集成安全边界从芯片内部扩展到封装、接口、供应链和设计链关键技术Chiplet 集成、UCIe / Die-to-Die 接口、信任根RoT、硬件木马检测、LLM 辅助设计与验证受影响人群芯片设计工程师、安全工程师、EDA 工具链开发者、系统架构师、供应链与质量负责人核心结论安全必须从“单品防护”升级为“系统信任链设计”LLM 只能当辅助工具不能当安全决策者验证方式设计评审、安全仿真、形式化验证、后硅测试、供应链审计、系统级安全启动测试这里先给出一个总体判断Chiplet 和 LLM 不是两个孤立趋势它们互为放大器。Chiplet 把供应链从纵向整合拉成横向协作参与方变多物理接触点变多LLM 则可以自动梳理文档、生成代码、分析日志大大缩短了从“理解一个芯片”到“找到它的薄弱点”的时间。安全团队如果不能把威胁模型重新定义清楚后面所有防护动作都可能是在旧地图上找新大陆。2. 为什么 Chiplet 和 LLM 会让硬件安全问题重新洗牌2.1 传统芯片时代的安全假设还能用吗传统单片 SoC 的设计流程相对集中从 RTL 编写、综合、布局布线到最终 GDS 交付多数环节可以由一个团队或一家供应商闭环完成。安全验证也相对清晰只要在 RTL 层做安全评审在验证阶段跑安全用例在流片后做安全启动和侧信道测试链条基本可控。但这个模型默认了一个重要前提整个芯片的每个环节都来自可信的供应链。Chiplet 把这个前提拆掉了。一颗封装芯片里可能包含来自多家供应商的 CPU die、GPU die、加速器 die、SerDes die、存储 die每一颗 die 都来自不同工艺节点、不同代工厂、不同封装和测试通道。任何一个 die 被插入后门、被替换成伪造版本或者在某一次测试过程中被读取了敏感数据整颗芯片的信任都不成立。硬件安全从“单芯片封闭验证”变成了“多参与方协同的开放生态安全”。2.2 Chiplet 让信任边界从芯片内部扩展到封装和接口Chiplet 技术最有价值的点是异构集成和复用但它带来的管理复杂度也是指数级上升。不同 die 之间的通信要经过 die-to-die 接口例如 UCIe、BoW、AIB 等这些接口既是数据通道也是攻击通道。一颗恶意 die 可以尝试通过接口读取其他 die 上的密钥、篡改正在传输的数据、发起拒绝服务甚至伪装成合法 die 发起身份欺骗。更麻烦的是封装和测试环节。单芯片时代扫描链测试、边界扫描、JTAG 测试端口通常只在内部使用风险相对可控。Chiplet 时代多颗 die 在封装前后都要经历更多测试和调试环节测试端口被恶意利用的可能性大幅增加。如果安全锁定机制没有在流片前设计好攻击者处理物理接触的机会就更多。2.3 LLM 把攻击自动化门槛拉低也把设计效率拉高LLM 在硬件设计中的角色有两种一是辅助设计与验证二是辅助攻击与漏洞挖掘。对设计团队来说LLM 可以自动生成寄存器传输级代码、生成验证断言、整理 IP 文档、分析 bug 报告甚至能把用户故事转换成安全需求。但这些便利都有代价模型生成的内容不可完全信任如果直接把 LLM 生成的 RTL 或验证环境拿去流片和使用会引入额外的风险。对攻击者来说LLM 同样降低了进入门槛。一个熟悉软件、但对硬件了解有限的攻击者可以用 LLM 快速读懂一份芯片白皮书、自动生成 Verilog 脚本、分析扫描链路径、编写故障注入脚本。这意味着硬件安全团队不能再假设攻击者需要多年半导体经验才能发起有效攻击。自动化让攻击面分析更快也让防御方必须用同样程度的自动化做安全验证否则双方效率不对等。3. Chiplet 架构与硬件设计流程变化3.1 Chiplet 究竟改变了芯片的什么形态传统 SoC 设计追求把所有功能集成到一颗大芯片上但这样做面临良率、工艺、成本多重压力。Chiplet 的思路是“化整为零”把 CPU、GPU、NPU、IO、存储控制等模块拆成多个 die再通过高性能互连封装在一起。每颗 die 可以使用最适合自己的工艺节点例如逻辑 die 用先进工艺模拟 die 用成熟工艺这既能提升整体性能又能摊薄成本。但这也意味着芯片层面的“物理信任单元”变了。过去一颗芯片是一体的做完整性检查时有明确边界现在一颗芯片是一个微系统每个 die 都有自己的制造、测试和密钥材料。安全设计不能再走“一个主密钥通吃全芯片”的老路必须考虑多信任根、跨 die 认证、接口级加密和隔离。3.2 设计流程中的信任链变化Chiplet 设计需要多方协同die 供应商、封装厂、测试厂、系统集成商都会接触到中间数据。RTL、网表、版图、测试向量、密钥配置文件等资产散落在多个组织之间任何一个环节管理不善都会造成知识产权泄露或者恶意篡改。尤其是第三方 die 供应商它提供的不仅仅是裸片还包括配套的 firmware、驱动和安全启动代码这套东西是否是可信的必须在设计阶段就完成审查。另一个被低估的问题是数据交换。Chiplet 设计中的接口协议文档、寄存器描述、安全启动流程图往往需要以电子形式在多组织之间传递。LLM 时代这些文档被自动分析和复制更加容易因此有必要对设计文档做分级权限管理避免把完整的信任链信息一次性暴露给所有协作方。3.3 验证复杂度上升安全验证必须前移多 die 协同仿真、物理验证、接口一致性测试、安全功能验证这些工作在 Chiplet 场景下会同时叠加。安全验证如果继续留在流片前最后阶段会发现很多问题已经来不及改。更合理的做法是在规格定义阶段就把安全需求拆解成可验证的 asserts在 RTL 阶段用形式化验证检查跨 die 接口的访问控制和隔离策略在 gate-level 阶段额外跑安全相关的故障注入仿真在封装阶段做安全启动流程和密钥烧写验证。安全验证前移是良率上的考虑也是资源上的考虑。越晚发现问题修改成本越高。对 Chiplet 这种大量复用第三方 die 的设计模式来说提前验证一个 die 的安全属性比等整颗封装完成后拆开排查要现实得多。4. LLM 在硬件设计中的机会与风险4.1 LLM 辅助硬件设计能做什么LLM 在硬件设计中的实际价值主要体现在几个方面把自然语言需求转换成 Verilog/SystemVerilog 原型自动生成 UVM 验证平台框架为安全模块生成断言对文档做摘要和合规性检查整理 IP 复用时的潜在风险清单。很多 EDA 厂商和芯片公司已经在尝试把 LLM 接入设计前端用它加速早期架构探索和代码草稿生成。用 LLM 写 RTL 有一个常见误区把它当成“更快的工程师”。实际上LLM 生成的设计代码更适合作为初稿或参考尤其是安全关键模块比如信任根、加解密引擎、访问控制逻辑绝不能直接采用未经安全评审的模型输出。更稳妥的方式是让 LLM 生成代码然后接上严格的代码评审、仿真验证、形式化验证和覆盖率分析流程。4.2 LLM 被攻击的风险同样适用于硬件设计硬件设计团队使用 LLM 时要警惕两类风险。一类是提示词注入攻击者可以把恶意指令藏在需求文档、开源 IP 描述或 bug report 里诱导 LLM 生成带后门的代码或绕过安全机制的验证环境。另一类是代码和文档污染如果 LLM 的训练数据里包含了不安全的 Verilog 样例模型可能在无意识中把不安全的写法引入到设计输出里。这类污染很难通过一次代码审查发现需要结合静态规则扫描和形式化验证来兜底。还有一种风险值得单独提出来LLM 生成了“看起来正确”的安全测试用例但它只是在低水平地覆盖已有路径没有真正补足安全空窗。如果团队过度信任 LLM 的覆盖率报告会误以为安全验证已经充分。因此在使用 LLM 做验证辅助时仍然需要有经验的安全工程师去判断哪些边界条件、故障注入场景和侧信道场景是真正需要覆盖的。4.3 结论LLM 是放大镜不是裁判把 LLM 放在硬件安全流程里比较合适的定位是“效率放大镜”。它可以快速把设计规格转化成断言、把攻击面清单整理出来、把重复性审查工作自动化但它不能替代安全评审、形式化验证、供应链审计和物理测试。设计团队应该在工具链里给 LLM 加“输出不可信”的标签所有模型生成内容必须进入与人类工程师相同甚至更严格的审查流程。5. 硬件安全的关键资产与威胁模型5.1 需要保护的硬件资产在 Chiplet 与 LLM 时代硬件资产的类型没有变但分布范围变大了。需要重点保护的包括IP 与设计数据RTL、网表、GDS、固件与引导代码Boot ROM、安全监控固件、信任根密钥与熔丝配置、运行时的敏感数据密钥、证书、用户数据以及供应链资产die ID、批次信息、测试记录。任何一条资产丢失或被篡改都有可能形成整条信任链的缺口。5.2 主要威胁模型威胁类型攻击场景防护思路硬件木马恶意 die 插入、GDS 修改、测试阶段植入完整性校验、ATPG 测试、形式化验证、供应链审核IP 窃取第三方供应商获取完整 RTL 或网表加密网表、逻辑混淆、权限隔离侧信道攻击密码运算中通过功耗或电磁泄露密钥掩码、隐藏电路、恒定时间实现故障注入电压毛刺、时钟毛刺绕过安全启动或访问控制传感器监测、冗余校验、安全状态机伪造芯片废旧或翻新芯片重新流入供应链PUF、安全 ID、批次溯源接口攻击恶意 die 通过 die-to-die 接口读取数据接口认证、流量隔离、安全代理LLM 辅助攻击自动分析硬件漏洞、生成攻击脚本强化威胁建模、自动化防御、资产最小化暴露测试端口滥用JTAG/扫描链被用于读取密钥或绕过安全模式测试端口锁定、安全策略熔丝、密钥分区隔离这张表是后续所有安全方案设计的基础。团队可以把它作为安全评审的输入逐条对照当前设计是否存在对应防护。注意这里的威胁没有覆盖所有场景只是从 Chiplet 和 LLM 两条主线出发先圈定最需要关注的类别。5.3 威胁模型需要持续演进威胁模型不是一次性文档。Chiplet 的参与方会变化LLM 的攻击能力也在快速演进。一个比较务实的做法是每季度或者在每个第三方 die 引入前重新做一遍威胁模型评审看有没有新的攻击路径出现。同时要把威胁模型和实际可用的检测手段绑定否则“我们认为存在风险”与“我们能发现风险”之间会出现巨大偏差。6. Chiplet 场景下的安全设计要点6.1 信任根在 Chiplet 中怎么布置单芯片时代的信任根方案很明确通常是一个 Secure Element 或 Boot ROM 加上 OTP/熔丝。Chiplet 场景下问题变成整个系统的信任根放在哪里如果只放在主 die 上其他 die 默认不可信那么每次跨 die 通信都要做认证如果每颗 die 都有自己的轻量信任根则需要一套跨 die 信任传递协议。更实用的设计是分层信任。系统级信任根放在拥有最高权限的主 die 上其余 die 拥有自己的唯一身份和密钥启动时通过主 die 做双向认证认证通过后才允许参与系统任务。这种设计既保留了单点可信的优势又避免了“所有 die 都必须完全可信”的过高要求。密钥分发和轮换策略需要在设计阶段确定不能到封装后再补。6.2 Die-to-Die 接口必须被当成网络边界来设计UCIe 这类接口在物理层上追求高带宽和低延迟但在安全层上必须回答几个问题链路是否支持发送方认证数据是否加密能否检测重放和篡改不同安全等级的 die 之间是否需要强制隔离这些问题如果不在接口协议里定义清楚后续在系统中加安全机制会遇到很大阻力。把 die-to-die 接口当作“芯片内部的网络边界”来管理是一个有效思路。接口上可以设计安全代理负责帧级加密、认证、访问控制表和异常事件上报。这样即使某一颗恶意 die 被插入它也必须在接口层面对抗认证机制无法直接读取其他 die 的内部数据。性能开销是设计难点但安全需求和性能需求并不是非此即彼可以在非安全数据通道和安全数据通道之间做分级。6.3 多供应商信任域管理Chiplet 生态里的每一颗 die 可能来自不同的信任域有的是自研可信 die有的是第三方不可信 die有的则介于两者之间。安全设计要把这些信任域显式建模出来为每个 die 分配安全等级并在总线上执行基于安全等级的访问控制。一个容易忽略的问题是第三方 die 的固件更新机制。很多 die 在产品生命周期内需要在线更新 firmware如果更新机制没有签名校验攻击者就可能通过伪造固件包来劫持整颗 die。因此在信任域管理中要同时覆盖硬件逻辑、固件、配置数据三部分缺一不可。6.4 封装与测试阶段的安全锁封装和测试阶段是 Chiplet 特有的高风险窗口。多颗 die 在封装前要分别做测试封装后还要做系统级测试每颗 die 的 JTAG 和扫描链都可能被接入测试设备。攻击者如果能在测试阶段读取到密钥材料就能在后续的芯片生命周期里实施更精准的攻击。针对这个风险设计上应该加入测试安全锁定模式正常出厂前通过熔丝或一次性编程寄存器禁用外部测试端口的敏感访问能力密钥材料只在安全子系统中读写测试链路无法直接访问。后硅测试阶段还需要有物理安全和流程安全控制例如测试机房准入、测试向量加密、日志审计等。7. 从硬件信任根到系统安全全栈安全视角7.1 硬件安全是软件安全策略的地基很多时候软件安全人员在排查问题时会看到一个现象应用层权限模型配置正确数据库权限也设置合理防火墙规则看起来没有问题但系统仍然暴露了敏感数据。这时往往要把视线往下移动检查底层硬件是否可信。硬件信任根、安全启动、CPU 隔离机制这些基础能力决定了上层安全软件是否能在可信环境中运行。典型的例子是 Secure Boot。BIOS 里如果开启了 Secure Boot并且信任链里的证书和密钥库配置正确系统启动过程就能阻止未签名的引导代码。很多主板上“Security Boot”开启后却无法启动系统多半是根证书或密钥配置问题。它背后对应的正是硬件信任根到系统固件、引导加载器之间的信任链设计。7.2 从 Windows Security、Spring Security 到数据库与 Web 边界安全运维人员经常接触的 Windows Security、Spring Security、MySQL 权限模型、Cloudflare Bots、Security Onion 等其实处在安全链条的不同层级。Windows Security 主要消费 CPU/TPM 提供的安全能力Spring Security 负责应用身份和授权MySQL 这类数据库的安全模型则通过 sql security definer、访问控制和审计日志来保护数据层Cloudflare Bots 防护的是 Web 边界Security Onion 这类流量监控平台负责网络侧检测。这些工具是必要的但它们的可信前提都包含一个更底层的事实CPU 和周边硬件没有被植入后门。如果芯片内部被恶意模块读取了密钥那么上层配置再严格也无济于事。反过来看上层安全工具的日志和报警恰恰可以成为发现硬件异常的一类线索。比如某个安全模块的运算时间异常可能提示底层硬件存在问题。安全建设应当自上而下、全链路打通而不仅仅是堆叠软件配置。8. 设计流程落地安全验证与 LLM 辅助的实践建议8.1 把安全需求写进设计规格而不是事后补很多芯片设计项目把安全验证放在流片前的最后阶段这几乎注定只会覆盖最低限度的合规项。更好的做法是在系统架构阶段就建立安全需求清单明确信任边界在哪里、哪些模块必须隔离、跨 die 通信是否需要加密、密钥如何管理、测试端口如何处理。这些需求要进入设计规格并分配到各个模块的验证计划中。可以把安全需求拆成“必选基线”和“增强项”按项目风险等级做取舍。8.2 在安全设计中加入 LLM但要包一层审查护栏使用 LLM 辅助硬件设计和安全分析时建议建立一个标准流程先让 LLM 生成代码或断言然后用专门的安全规则进行静态扫描再通过形式化验证或仿真器做深度检查最后必须由资深安全工程师做人工评审。对安全关键模块不能省掉人工评审这一步。流程里还要考虑提示词的安全性避免把内部机密内容直接输入到云端 LLM 服务防止敏感信息外泄。8.3 供应链安全评估清单无论使用 Chiplet 还是传统 SoC供应链安全都应该有一套可执行的评估清单。至少包括第三方 die 或 IP 提供商的交付物是否包含完整的来源与授权记录RTL/网表/GDS 在传输过程中是否有加密和哈希校验是否对供应商的安全资质进行过审查采购的 die 是否有唯一 ID 和可溯源的批次信息封装完成后是否做 X 光或物理检查以确认内部 die 与预期一致。这套清单可以交给质量或采购团队协作执行而不是单靠设计团队。8.4 后硅测试与安全启动验证封装完成后安全验证并没有结束。后硅阶段要重点验证安全启动流程确认 Boot ROM 能正确验证固件签名并建立信任链确认不同安全等级的 die 在启动期间能够完成双向认证测试端口和调试接口在正常产品模式下已经被锁定密钥材料写入熔丝或 OTP 后外部无法通过扫描链读取。这些测试要在多片样本上重复执行并保留日志以支持后续追溯。8.5 自动化工具链的引入路径芯片安全验证需要大量重复性检查适合用自动化工具链来承接。可以优先实现几类能力对全设计跑安全相关规则检查对新增接口和访问控制逻辑自动生成安全断言收集与安全相关的覆盖率数据对供应链交付物做哈希和版本自动比对。LLM 可以在这些工具链里作为前端交互入口降低使用门槛但底层判断逻辑仍然要基于形式化工具和经过验证的规则集。先从一个小模块开始试点跑通后再逐步推广到整个设计流程比一开始就铺开所有自动化要稳妥得多。9. 常见问题与排查思路问题现象可能原因排查思路第三方 die 被替换或异常供应链管理缺失无法追溯批次建立供应商清单比对 die ID封装后做物理检查仿真中安全功能正常流片后失效后硅测试端口被旁路熔丝配置错误检查 eFuse/OTP 烧写流程确认测试端口锁定生效LLM 生成的 RTL 存在可疑逻辑模型输出未经过安全审查或提示词注入引入静态规则扫描、形式化验证、人工代码评审跨 die 数据被异常读取接口层未做认证和访问控制启用链路上认证、流量隔离检查接口安全代理配置系统启动时 Secure Boot 报错根证书或信任链配置不正确核对硬件信任根证书库和 BIOS 密钥配置应用层权限校验失败但找不到原因底层可信环境未建立检查 TPM/Secure Boot 是否启用确认应用运行环境可信文件或流程出现 security 配置报错权限模型或策略与底层安全状态不匹配核对操作系统、数据库、应用的访问控制策略与硬件信任状态批量安全验证任务卡住工具链死锁或模型文件缺失检查日志与依赖拆成小规模任务重跑使用 LLM 辅助设计时敏感数据外泄数据被输入到外部模型服务改用私有化部署模型增加数据脱敏过滤这张排查表只是一个起点。实际项目中问题往往不会以单一现象出现而是多个现象叠加。排查时建议先确认硬件信任链是否完整再逐层排查固件、驱动、操作系统和应用配置。不要一上来就怀疑工具问题很多底层安全配置错误往往最先表现为上层莫名其妙的功能异常。10. 总结与下一步Chiplet 和 LLM 对硬件设计安全提出的挑战本质上是“信任边界多元化”和“攻防效率失衡”两个合力的结果。Chiplet 让一颗芯片从内部闭环变成多参与方协作的开放生态LLM 则同时把设计和攻击的自动化水平拉高。对安全团队来说真正可靠的做法不是等待更完美的工具而是先把威胁模型、信任根布局、接口安全和供应链审计这些基础工作做好。建议第一步先做一个“安全现状盘点”梳理当前项目涉及的第三方 die/IP 清单建立威胁模型列出现有防护覆盖与缺口第二步选择安全关键模块把安全需求写进设计规格并安排验证计划第三步再引入 LLM 辅助工具把它限制在审查、生成草稿、整理文档这类非决策环节。这套路线不需要一次完成但每一步都要有可验证的交付物。下一步值得关注的演进方向包括UCIe 接口安全扩展的定义与实现跨 die 信任根协议的标准化硬件木马检测中 ML/LLM 的辅助能力落地以及把系统级安全启动验证从单芯片扩展到 Chiplet 微系统。每一项都存在不小的工程挑战但也是安全工程师和芯片设计工程师形成合力的场景。先把基础信任机制做扎实再谈效率提升这个顺序不会错。 Chiplet与LLM时代：硬件安全边界重构与信任链设计指南
如果把“Chiplet”和“LLM”两个词放到同一张工作台上很多人的第一反应是一个在讲芯片封装和异构集成一个在讲大语言模型工具两者为什么要放到一起讨论安全这两件事正好同时发生让硬件安全从“芯片内部的事”变成了“整个产业链和算法生态的事”。Chiplet 把一颗 SoC 拆散成多颗来自不同供应商、不同工艺节点的 die再用 UCIe 这类接口拼装在一起LLM 则把硬件设计的自动化水平同时拉高——它既能自动生成 RTL、验证代码、安全断言也能被用来做攻击面分析、恶意代码生成和漏洞挖掘。设计门槛在降低攻击门槛也在降低但信任边界却变得更碎片化。这篇文章不绑定具体型号和产线而是把“硬件设计 安全 Chiplet LLM”四个关键词放在同一套逻辑里先讲清架构变化带来哪些新的安全边界再给出威胁模型与防护思路最后落到设计流程里怎么把安全验证和 LLM 辅助工具用起来。适合芯片设计工程师、EDA 与安全研究员、后端系统架构师以及所有关心硬件可信根的开发者和安全运维人员阅读。1. 主题速览维度说明文章主题Chiplet 与 LLM 时代的硬件设计安全核心变化芯片从单片 SoC 转向异构多 die 集成安全边界从芯片内部扩展到封装、接口、供应链和设计链关键技术Chiplet 集成、UCIe / Die-to-Die 接口、信任根RoT、硬件木马检测、LLM 辅助设计与验证受影响人群芯片设计工程师、安全工程师、EDA 工具链开发者、系统架构师、供应链与质量负责人核心结论安全必须从“单品防护”升级为“系统信任链设计”LLM 只能当辅助工具不能当安全决策者验证方式设计评审、安全仿真、形式化验证、后硅测试、供应链审计、系统级安全启动测试这里先给出一个总体判断Chiplet 和 LLM 不是两个孤立趋势它们互为放大器。Chiplet 把供应链从纵向整合拉成横向协作参与方变多物理接触点变多LLM 则可以自动梳理文档、生成代码、分析日志大大缩短了从“理解一个芯片”到“找到它的薄弱点”的时间。安全团队如果不能把威胁模型重新定义清楚后面所有防护动作都可能是在旧地图上找新大陆。2. 为什么 Chiplet 和 LLM 会让硬件安全问题重新洗牌2.1 传统芯片时代的安全假设还能用吗传统单片 SoC 的设计流程相对集中从 RTL 编写、综合、布局布线到最终 GDS 交付多数环节可以由一个团队或一家供应商闭环完成。安全验证也相对清晰只要在 RTL 层做安全评审在验证阶段跑安全用例在流片后做安全启动和侧信道测试链条基本可控。但这个模型默认了一个重要前提整个芯片的每个环节都来自可信的供应链。Chiplet 把这个前提拆掉了。一颗封装芯片里可能包含来自多家供应商的 CPU die、GPU die、加速器 die、SerDes die、存储 die每一颗 die 都来自不同工艺节点、不同代工厂、不同封装和测试通道。任何一个 die 被插入后门、被替换成伪造版本或者在某一次测试过程中被读取了敏感数据整颗芯片的信任都不成立。硬件安全从“单芯片封闭验证”变成了“多参与方协同的开放生态安全”。2.2 Chiplet 让信任边界从芯片内部扩展到封装和接口Chiplet 技术最有价值的点是异构集成和复用但它带来的管理复杂度也是指数级上升。不同 die 之间的通信要经过 die-to-die 接口例如 UCIe、BoW、AIB 等这些接口既是数据通道也是攻击通道。一颗恶意 die 可以尝试通过接口读取其他 die 上的密钥、篡改正在传输的数据、发起拒绝服务甚至伪装成合法 die 发起身份欺骗。更麻烦的是封装和测试环节。单芯片时代扫描链测试、边界扫描、JTAG 测试端口通常只在内部使用风险相对可控。Chiplet 时代多颗 die 在封装前后都要经历更多测试和调试环节测试端口被恶意利用的可能性大幅增加。如果安全锁定机制没有在流片前设计好攻击者处理物理接触的机会就更多。2.3 LLM 把攻击自动化门槛拉低也把设计效率拉高LLM 在硬件设计中的角色有两种一是辅助设计与验证二是辅助攻击与漏洞挖掘。对设计团队来说LLM 可以自动生成寄存器传输级代码、生成验证断言、整理 IP 文档、分析 bug 报告甚至能把用户故事转换成安全需求。但这些便利都有代价模型生成的内容不可完全信任如果直接把 LLM 生成的 RTL 或验证环境拿去流片和使用会引入额外的风险。对攻击者来说LLM 同样降低了进入门槛。一个熟悉软件、但对硬件了解有限的攻击者可以用 LLM 快速读懂一份芯片白皮书、自动生成 Verilog 脚本、分析扫描链路径、编写故障注入脚本。这意味着硬件安全团队不能再假设攻击者需要多年半导体经验才能发起有效攻击。自动化让攻击面分析更快也让防御方必须用同样程度的自动化做安全验证否则双方效率不对等。3. Chiplet 架构与硬件设计流程变化3.1 Chiplet 究竟改变了芯片的什么形态传统 SoC 设计追求把所有功能集成到一颗大芯片上但这样做面临良率、工艺、成本多重压力。Chiplet 的思路是“化整为零”把 CPU、GPU、NPU、IO、存储控制等模块拆成多个 die再通过高性能互连封装在一起。每颗 die 可以使用最适合自己的工艺节点例如逻辑 die 用先进工艺模拟 die 用成熟工艺这既能提升整体性能又能摊薄成本。但这也意味着芯片层面的“物理信任单元”变了。过去一颗芯片是一体的做完整性检查时有明确边界现在一颗芯片是一个微系统每个 die 都有自己的制造、测试和密钥材料。安全设计不能再走“一个主密钥通吃全芯片”的老路必须考虑多信任根、跨 die 认证、接口级加密和隔离。3.2 设计流程中的信任链变化Chiplet 设计需要多方协同die 供应商、封装厂、测试厂、系统集成商都会接触到中间数据。RTL、网表、版图、测试向量、密钥配置文件等资产散落在多个组织之间任何一个环节管理不善都会造成知识产权泄露或者恶意篡改。尤其是第三方 die 供应商它提供的不仅仅是裸片还包括配套的 firmware、驱动和安全启动代码这套东西是否是可信的必须在设计阶段就完成审查。另一个被低估的问题是数据交换。Chiplet 设计中的接口协议文档、寄存器描述、安全启动流程图往往需要以电子形式在多组织之间传递。LLM 时代这些文档被自动分析和复制更加容易因此有必要对设计文档做分级权限管理避免把完整的信任链信息一次性暴露给所有协作方。3.3 验证复杂度上升安全验证必须前移多 die 协同仿真、物理验证、接口一致性测试、安全功能验证这些工作在 Chiplet 场景下会同时叠加。安全验证如果继续留在流片前最后阶段会发现很多问题已经来不及改。更合理的做法是在规格定义阶段就把安全需求拆解成可验证的 asserts在 RTL 阶段用形式化验证检查跨 die 接口的访问控制和隔离策略在 gate-level 阶段额外跑安全相关的故障注入仿真在封装阶段做安全启动流程和密钥烧写验证。安全验证前移是良率上的考虑也是资源上的考虑。越晚发现问题修改成本越高。对 Chiplet 这种大量复用第三方 die 的设计模式来说提前验证一个 die 的安全属性比等整颗封装完成后拆开排查要现实得多。4. LLM 在硬件设计中的机会与风险4.1 LLM 辅助硬件设计能做什么LLM 在硬件设计中的实际价值主要体现在几个方面把自然语言需求转换成 Verilog/SystemVerilog 原型自动生成 UVM 验证平台框架为安全模块生成断言对文档做摘要和合规性检查整理 IP 复用时的潜在风险清单。很多 EDA 厂商和芯片公司已经在尝试把 LLM 接入设计前端用它加速早期架构探索和代码草稿生成。用 LLM 写 RTL 有一个常见误区把它当成“更快的工程师”。实际上LLM 生成的设计代码更适合作为初稿或参考尤其是安全关键模块比如信任根、加解密引擎、访问控制逻辑绝不能直接采用未经安全评审的模型输出。更稳妥的方式是让 LLM 生成代码然后接上严格的代码评审、仿真验证、形式化验证和覆盖率分析流程。4.2 LLM 被攻击的风险同样适用于硬件设计硬件设计团队使用 LLM 时要警惕两类风险。一类是提示词注入攻击者可以把恶意指令藏在需求文档、开源 IP 描述或 bug report 里诱导 LLM 生成带后门的代码或绕过安全机制的验证环境。另一类是代码和文档污染如果 LLM 的训练数据里包含了不安全的 Verilog 样例模型可能在无意识中把不安全的写法引入到设计输出里。这类污染很难通过一次代码审查发现需要结合静态规则扫描和形式化验证来兜底。还有一种风险值得单独提出来LLM 生成了“看起来正确”的安全测试用例但它只是在低水平地覆盖已有路径没有真正补足安全空窗。如果团队过度信任 LLM 的覆盖率报告会误以为安全验证已经充分。因此在使用 LLM 做验证辅助时仍然需要有经验的安全工程师去判断哪些边界条件、故障注入场景和侧信道场景是真正需要覆盖的。4.3 结论LLM 是放大镜不是裁判把 LLM 放在硬件安全流程里比较合适的定位是“效率放大镜”。它可以快速把设计规格转化成断言、把攻击面清单整理出来、把重复性审查工作自动化但它不能替代安全评审、形式化验证、供应链审计和物理测试。设计团队应该在工具链里给 LLM 加“输出不可信”的标签所有模型生成内容必须进入与人类工程师相同甚至更严格的审查流程。5. 硬件安全的关键资产与威胁模型5.1 需要保护的硬件资产在 Chiplet 与 LLM 时代硬件资产的类型没有变但分布范围变大了。需要重点保护的包括IP 与设计数据RTL、网表、GDS、固件与引导代码Boot ROM、安全监控固件、信任根密钥与熔丝配置、运行时的敏感数据密钥、证书、用户数据以及供应链资产die ID、批次信息、测试记录。任何一条资产丢失或被篡改都有可能形成整条信任链的缺口。5.2 主要威胁模型威胁类型攻击场景防护思路硬件木马恶意 die 插入、GDS 修改、测试阶段植入完整性校验、ATPG 测试、形式化验证、供应链审核IP 窃取第三方供应商获取完整 RTL 或网表加密网表、逻辑混淆、权限隔离侧信道攻击密码运算中通过功耗或电磁泄露密钥掩码、隐藏电路、恒定时间实现故障注入电压毛刺、时钟毛刺绕过安全启动或访问控制传感器监测、冗余校验、安全状态机伪造芯片废旧或翻新芯片重新流入供应链PUF、安全 ID、批次溯源接口攻击恶意 die 通过 die-to-die 接口读取数据接口认证、流量隔离、安全代理LLM 辅助攻击自动分析硬件漏洞、生成攻击脚本强化威胁建模、自动化防御、资产最小化暴露测试端口滥用JTAG/扫描链被用于读取密钥或绕过安全模式测试端口锁定、安全策略熔丝、密钥分区隔离这张表是后续所有安全方案设计的基础。团队可以把它作为安全评审的输入逐条对照当前设计是否存在对应防护。注意这里的威胁没有覆盖所有场景只是从 Chiplet 和 LLM 两条主线出发先圈定最需要关注的类别。5.3 威胁模型需要持续演进威胁模型不是一次性文档。Chiplet 的参与方会变化LLM 的攻击能力也在快速演进。一个比较务实的做法是每季度或者在每个第三方 die 引入前重新做一遍威胁模型评审看有没有新的攻击路径出现。同时要把威胁模型和实际可用的检测手段绑定否则“我们认为存在风险”与“我们能发现风险”之间会出现巨大偏差。6. Chiplet 场景下的安全设计要点6.1 信任根在 Chiplet 中怎么布置单芯片时代的信任根方案很明确通常是一个 Secure Element 或 Boot ROM 加上 OTP/熔丝。Chiplet 场景下问题变成整个系统的信任根放在哪里如果只放在主 die 上其他 die 默认不可信那么每次跨 die 通信都要做认证如果每颗 die 都有自己的轻量信任根则需要一套跨 die 信任传递协议。更实用的设计是分层信任。系统级信任根放在拥有最高权限的主 die 上其余 die 拥有自己的唯一身份和密钥启动时通过主 die 做双向认证认证通过后才允许参与系统任务。这种设计既保留了单点可信的优势又避免了“所有 die 都必须完全可信”的过高要求。密钥分发和轮换策略需要在设计阶段确定不能到封装后再补。6.2 Die-to-Die 接口必须被当成网络边界来设计UCIe 这类接口在物理层上追求高带宽和低延迟但在安全层上必须回答几个问题链路是否支持发送方认证数据是否加密能否检测重放和篡改不同安全等级的 die 之间是否需要强制隔离这些问题如果不在接口协议里定义清楚后续在系统中加安全机制会遇到很大阻力。把 die-to-die 接口当作“芯片内部的网络边界”来管理是一个有效思路。接口上可以设计安全代理负责帧级加密、认证、访问控制表和异常事件上报。这样即使某一颗恶意 die 被插入它也必须在接口层面对抗认证机制无法直接读取其他 die 的内部数据。性能开销是设计难点但安全需求和性能需求并不是非此即彼可以在非安全数据通道和安全数据通道之间做分级。6.3 多供应商信任域管理Chiplet 生态里的每一颗 die 可能来自不同的信任域有的是自研可信 die有的是第三方不可信 die有的则介于两者之间。安全设计要把这些信任域显式建模出来为每个 die 分配安全等级并在总线上执行基于安全等级的访问控制。一个容易忽略的问题是第三方 die 的固件更新机制。很多 die 在产品生命周期内需要在线更新 firmware如果更新机制没有签名校验攻击者就可能通过伪造固件包来劫持整颗 die。因此在信任域管理中要同时覆盖硬件逻辑、固件、配置数据三部分缺一不可。6.4 封装与测试阶段的安全锁封装和测试阶段是 Chiplet 特有的高风险窗口。多颗 die 在封装前要分别做测试封装后还要做系统级测试每颗 die 的 JTAG 和扫描链都可能被接入测试设备。攻击者如果能在测试阶段读取到密钥材料就能在后续的芯片生命周期里实施更精准的攻击。针对这个风险设计上应该加入测试安全锁定模式正常出厂前通过熔丝或一次性编程寄存器禁用外部测试端口的敏感访问能力密钥材料只在安全子系统中读写测试链路无法直接访问。后硅测试阶段还需要有物理安全和流程安全控制例如测试机房准入、测试向量加密、日志审计等。7. 从硬件信任根到系统安全全栈安全视角7.1 硬件安全是软件安全策略的地基很多时候软件安全人员在排查问题时会看到一个现象应用层权限模型配置正确数据库权限也设置合理防火墙规则看起来没有问题但系统仍然暴露了敏感数据。这时往往要把视线往下移动检查底层硬件是否可信。硬件信任根、安全启动、CPU 隔离机制这些基础能力决定了上层安全软件是否能在可信环境中运行。典型的例子是 Secure Boot。BIOS 里如果开启了 Secure Boot并且信任链里的证书和密钥库配置正确系统启动过程就能阻止未签名的引导代码。很多主板上“Security Boot”开启后却无法启动系统多半是根证书或密钥配置问题。它背后对应的正是硬件信任根到系统固件、引导加载器之间的信任链设计。7.2 从 Windows Security、Spring Security 到数据库与 Web 边界安全运维人员经常接触的 Windows Security、Spring Security、MySQL 权限模型、Cloudflare Bots、Security Onion 等其实处在安全链条的不同层级。Windows Security 主要消费 CPU/TPM 提供的安全能力Spring Security 负责应用身份和授权MySQL 这类数据库的安全模型则通过 sql security definer、访问控制和审计日志来保护数据层Cloudflare Bots 防护的是 Web 边界Security Onion 这类流量监控平台负责网络侧检测。这些工具是必要的但它们的可信前提都包含一个更底层的事实CPU 和周边硬件没有被植入后门。如果芯片内部被恶意模块读取了密钥那么上层配置再严格也无济于事。反过来看上层安全工具的日志和报警恰恰可以成为发现硬件异常的一类线索。比如某个安全模块的运算时间异常可能提示底层硬件存在问题。安全建设应当自上而下、全链路打通而不仅仅是堆叠软件配置。8. 设计流程落地安全验证与 LLM 辅助的实践建议8.1 把安全需求写进设计规格而不是事后补很多芯片设计项目把安全验证放在流片前的最后阶段这几乎注定只会覆盖最低限度的合规项。更好的做法是在系统架构阶段就建立安全需求清单明确信任边界在哪里、哪些模块必须隔离、跨 die 通信是否需要加密、密钥如何管理、测试端口如何处理。这些需求要进入设计规格并分配到各个模块的验证计划中。可以把安全需求拆成“必选基线”和“增强项”按项目风险等级做取舍。8.2 在安全设计中加入 LLM但要包一层审查护栏使用 LLM 辅助硬件设计和安全分析时建议建立一个标准流程先让 LLM 生成代码或断言然后用专门的安全规则进行静态扫描再通过形式化验证或仿真器做深度检查最后必须由资深安全工程师做人工评审。对安全关键模块不能省掉人工评审这一步。流程里还要考虑提示词的安全性避免把内部机密内容直接输入到云端 LLM 服务防止敏感信息外泄。8.3 供应链安全评估清单无论使用 Chiplet 还是传统 SoC供应链安全都应该有一套可执行的评估清单。至少包括第三方 die 或 IP 提供商的交付物是否包含完整的来源与授权记录RTL/网表/GDS 在传输过程中是否有加密和哈希校验是否对供应商的安全资质进行过审查采购的 die 是否有唯一 ID 和可溯源的批次信息封装完成后是否做 X 光或物理检查以确认内部 die 与预期一致。这套清单可以交给质量或采购团队协作执行而不是单靠设计团队。8.4 后硅测试与安全启动验证封装完成后安全验证并没有结束。后硅阶段要重点验证安全启动流程确认 Boot ROM 能正确验证固件签名并建立信任链确认不同安全等级的 die 在启动期间能够完成双向认证测试端口和调试接口在正常产品模式下已经被锁定密钥材料写入熔丝或 OTP 后外部无法通过扫描链读取。这些测试要在多片样本上重复执行并保留日志以支持后续追溯。8.5 自动化工具链的引入路径芯片安全验证需要大量重复性检查适合用自动化工具链来承接。可以优先实现几类能力对全设计跑安全相关规则检查对新增接口和访问控制逻辑自动生成安全断言收集与安全相关的覆盖率数据对供应链交付物做哈希和版本自动比对。LLM 可以在这些工具链里作为前端交互入口降低使用门槛但底层判断逻辑仍然要基于形式化工具和经过验证的规则集。先从一个小模块开始试点跑通后再逐步推广到整个设计流程比一开始就铺开所有自动化要稳妥得多。9. 常见问题与排查思路问题现象可能原因排查思路第三方 die 被替换或异常供应链管理缺失无法追溯批次建立供应商清单比对 die ID封装后做物理检查仿真中安全功能正常流片后失效后硅测试端口被旁路熔丝配置错误检查 eFuse/OTP 烧写流程确认测试端口锁定生效LLM 生成的 RTL 存在可疑逻辑模型输出未经过安全审查或提示词注入引入静态规则扫描、形式化验证、人工代码评审跨 die 数据被异常读取接口层未做认证和访问控制启用链路上认证、流量隔离检查接口安全代理配置系统启动时 Secure Boot 报错根证书或信任链配置不正确核对硬件信任根证书库和 BIOS 密钥配置应用层权限校验失败但找不到原因底层可信环境未建立检查 TPM/Secure Boot 是否启用确认应用运行环境可信文件或流程出现 security 配置报错权限模型或策略与底层安全状态不匹配核对操作系统、数据库、应用的访问控制策略与硬件信任状态批量安全验证任务卡住工具链死锁或模型文件缺失检查日志与依赖拆成小规模任务重跑使用 LLM 辅助设计时敏感数据外泄数据被输入到外部模型服务改用私有化部署模型增加数据脱敏过滤这张排查表只是一个起点。实际项目中问题往往不会以单一现象出现而是多个现象叠加。排查时建议先确认硬件信任链是否完整再逐层排查固件、驱动、操作系统和应用配置。不要一上来就怀疑工具问题很多底层安全配置错误往往最先表现为上层莫名其妙的功能异常。10. 总结与下一步Chiplet 和 LLM 对硬件设计安全提出的挑战本质上是“信任边界多元化”和“攻防效率失衡”两个合力的结果。Chiplet 让一颗芯片从内部闭环变成多参与方协作的开放生态LLM 则同时把设计和攻击的自动化水平拉高。对安全团队来说真正可靠的做法不是等待更完美的工具而是先把威胁模型、信任根布局、接口安全和供应链审计这些基础工作做好。建议第一步先做一个“安全现状盘点”梳理当前项目涉及的第三方 die/IP 清单建立威胁模型列出现有防护覆盖与缺口第二步选择安全关键模块把安全需求写进设计规格并安排验证计划第三步再引入 LLM 辅助工具把它限制在审查、生成草稿、整理文档这类非决策环节。这套路线不需要一次完成但每一步都要有可验证的交付物。下一步值得关注的演进方向包括UCIe 接口安全扩展的定义与实现跨 die 信任根协议的标准化硬件木马检测中 ML/LLM 的辅助能力落地以及把系统级安全启动验证从单芯片扩展到 Chiplet 微系统。每一项都存在不小的工程挑战但也是安全工程师和芯片设计工程师形成合力的场景。先把基础信任机制做扎实再谈效率提升这个顺序不会错。