汽车行业最近有个动向挺值得琢磨Intrinsic ID 正式发布了面向汽车市场的硬件根信任Hardware Root-of-Trust解决方案而且直接对标功能安全标准Functional Safety Standards来打。消息本身不算长但干这行的都清楚这个首个满足功能安全标准的说法背后搅动的不只是一家公司的产品线而是整个汽车电子安全架构的设计思路。先说为什么这个事值得单拎出来聊。过去几年汽车上越来越多的控制器、传感器、网联模块在往车里塞车已经从一个纯机械产品变成了跑在轮子上的计算平台。计算平台多了攻击面自然就大。随便一辆新车的电子控制单元ECU数量都奔着上百个去再加上OTA升级、V2X通信、自动驾驶域控制器这些新功能信息安全如果只停留在某个模块加个加密芯片这个层面根本兜不住。安全必须是分层、成体系的而体系需要一个能站得住的根基——这就是硬件信任根。然而问题也随之而来信任根本身也是硬件它自己也会老化、会有随机故障、也会在某些极端工况下失效。如果根基自己先垮了整个安全体系等于白搭。这恰好就是功能安全要管的事。所以Intrinsic ID这次的发布本质上是在回答一个之前整个行业都没完全解决的问题怎么让安全的根同时是可靠的根。1. 为什么汽车市场的信任根绕不开功能安全这道门槛1.1 功能安全管的是硬件自己坏了怎么办很多刚接触汽车电子的朋友会把信息安全和功能安全当成一回事其实两个体系关注的问题完全不一样。信息安全防的是有人使坏功能安全防的是自己坏掉。后者在汽车行业有一套专门的标准——ISO 26262它管的是电控系统在发生随机硬件故障、系统性设计失误时能不能把风险控制在可接受的范围内。用大白话讲恶意攻击者想篡改你的刹车信号那是信息安全的问题但刹车控制器自己的一块存储单元因为老化突然写错了数据那是功能安全的问题。这两件事在传统IT领域可以分开处理但在汽车上必须同时考虑因为汽车电控系统的每一个关键操作都直接关联物理运动。方向盘、油门、刹车这些部件的控制器如果出现一个未被发现的硬件故障后果可能比一次网络攻击更直接。硬件信任根在这套逻辑里处于一个特殊位置它是整个安全体系的保险丝。安全启动要依赖它验证固件通信加密要依赖它管理密钥OTA升级要依赖它鉴别固件包。如果信任根自身出现随机故障所有基于它建立的安全能力都会同步失效。这也意味着信任根芯片不能只说自己安全性很强还必须证明自己在故障模式下依然安全这正是功能安全标准的核心诉求。1.2 信息安全与功能安全在车里早就分不开了放在五年前安全团队和功能安全团队在车企里通常是两个部门、两套流程、甚至两家供应商。但现在越来越多项目意识到这两件事在汽车电子架构里根本没法完全切割。举个例子一辆支持OTA的智能汽车云端下发的固件包如果被篡改导致某个ECU的软件逻辑出错最终触发了刹车系统的错误动作。这个事故你说是信息安全问题还是功能安全问题攻击路径是信息安全的但最终后果是功能安全的。所以在最新的行业实践里大家开始强调一条安全链从芯片的信任根出发到启动过程、运行时环境、关键应用再到云端服务每个环节既要考虑抗攻击也要考虑硬件自身的可靠性。这也是为什么Intrinsic ID这款硬件信任根方案要专门去满足功能安全标准。过去汽车芯片厂商选安全IP关注点主要放在能不能防住攻击者上面比如密钥怎么存、算法有多强、有没有防侧信道攻击的能力。但现在的车规项目客户第一句话往往会问这颗IP过了ISO 26262没有有没有ASIL等级FMEDA报告能看吗这个变化很实在因为对于车厂来说一颗安全IP如果本身没有功能安全认证整车的安全论证链条就断了一截后面的审核和备案都会非常痛苦。2. Intrinsic ID的PUF方案凭什么拿下首个2.1 SRAM PUF上电瞬间生成的芯片指纹Intrinsic ID这家公司在安全圈子里向来以物理不可克隆函数PUFPhysically Unclonable Function技术出名这次发布的核心还是他们的老本行SRAM PUF方案。PUF这个技术听起来玄乎原理其实不复杂芯片在制造过程中晶体管之间的微小差异是随机且不可控的即便是同一块晶圆、同一台光刻机生产出来的芯片晶体管之间的阈值电压也会存在细微偏差。这种偏差几乎是无法复制的就像人的指纹。SRAM PUF利用的正是这一特性。SRAM单元在上电的瞬间每个存储单元会随机偏向逻辑0或逻辑1而由于制造偏差的影响某些单元会稳定地偏向0某些单元会稳定地偏向1。这意味着每次给芯片上电读出来的数据其实是一串由物理特性决定的、独一无二的指纹。把这串指纹通过算法加工就能生成可靠的密钥。在我参与的多个安全芯片项目里SRAM PUF最吸引人的一点在于密钥不是存在芯片里的而是每次上电时长出来的。芯片关机后密钥在物理上就消失了下次上电再重新生成。这从根上消灭了密钥被静态提取这个传统安全芯片最头疼的问题。如果攻击者用探针手段去读取存储介质会发现根本没有完整的密钥可以偷。2.2 对比eFuse和SEPUF在成本和可靠性上的优势在Intrinsic ID方案出现之前汽车安全芯片常用的密钥存储方案主要有两种一种是在片上集成一次性可编程存储eFuse/OTP把密钥在出厂前烧录进去另一种是外挂一颗独立的安全芯片SE或者HSM专门负责密钥存储和加密运算。这两种方案都有各自的软肋。eFuse的优点是简单直接但密钥一旦烧录进去就是静态的总线读取、功耗分析、故障注入攻击都有可能把密钥扒出来。而且eFuse在车规场景下还有一个实际痛点它需要额外的编程电压和高压晶体管不但增加了芯片面积高压电路本身在寿命周期内的可靠性也更难论证。对于ISO 26262来说多一个高压模块就多一堆失效模式需要分析认证成本居高不下。独立SE芯片的方案安全性更高但成本也高。一颗合规的车规级SE芯片可能要额外增加好几美元BOM成本还要占一块PCB面积。更麻烦的是SE芯片自身也有密钥管理问题——它自己的根密钥怎么保护最后一层密钥总会落到某个静态存储介质里这只是把问题转移了。PUF则用另一种思路绕开了这个死结密钥不存在静态存储里每次上电重新生成攻击者没有秘钥存储这个固定的攻击目标。同时SRAM在车规芯片里是极其成熟的标准单元没有高压、没有特殊工艺可靠性数据积累充分这对后续的功能安全认证是巨大的加分项。2.3 一个IP要满足功能安全实际做了哪些事这次Intrinsic ID能说自己是首个满足功能安全标准的硬件根信任方案不是请个检测机构来做个简单测试就行的。根据行业内功能安全认证的一般流程一颗安全IP要做到这一点至少要完成以下几类工作首先要对IP内部所有功能模块做FMEDA分析把每一个模块可能出现的失效模式都列出来比如寄存器位翻转、状态机卡死、总线错误逐一分析失效的影响和可检测性其次要设计相应的安全机制比如错误纠正码ECC、双核锁步、CRC校验、内置自测BIST等最后要进行完整的失效注入测试用模拟方式验证安全机制确实能在故障发生时把系统带到安全状态。这套流程做下来工作量相当大。尤其是PUF相关的模块其密钥生成过程涉及模拟电路特性失效分析比纯粹的数字逻辑更复杂。温度漂移、电压波动、器件老化都会影响SRAM单元的稳定性。Intrinsic ID之所以能率先做到说明他们在车规领域至少已经积累了好几年不可能是临时起意。而且需要注意的是交付的功能安全文档包不是一次性的IP更新一个版本所有安全分析都要跟着重新做这是个持续投入很大的方向。3. ISO 26262认证对一颗安全IP意味着什么3.1 先搞清楚ASIL等级从A到D差异有多大ISO 26262把汽车安全完整性等级分成了A、B、C、D四个等级D最严格。怎么理解这个等级它不是一个简单的评分而是跟可接受的风险概率挂钩的。ASIL等级越高系统可以容忍的失效概率就越低。如果某个系统被定级为ASIL-D那么它平均每小时的危险失效概率要低于一个极小的阈值折算下来相关硬件单点失效的指标要求也极为苛刻。在整车里并不是所有系统都需要ASIL-D。比如转向、制动这类直接影响车辆可控性的系统通常要求ASIL-D而一些信息娱乐、车载导航这类故障不会直接造成人身伤害的系统可能ASIL-A就够了。硬件信任根比较特殊它的客户是整车上几乎所有的ECU——安全启动、关键数据存储、通信认证都用到它。所以它最好能支持到尽可能高的等级至少得覆盖ASIL-B以上才能满足多数功能域的需求。还有一种理解方式ASIL等级像是一条可靠性承诺线。一颗IP声称支持ASIL-D意味着它提供的每一个安全机制都经过了严格分析目标失效概率极低故障自我诊断能力极强。这跟这颗芯片质量不错完全不在一个层次上。后者是产品质量问题前者是整个开发流程和验证深度的系统性问题。3.2 FMEDA背后安全指标是用数字说话的功能安全认证里最核心的一份文档叫FMEDAFailure Modes, Effects and Diagnostic Analysis简单说就是把芯片里每个模块可能怎么坏、坏了对系统有什么影响、靠什么机制发现这种故障全部列成一张大表逐项分析。有了这张表后续的SPFM单点故障度量、LFM潜在故障度量和FIT单位时间失效数这些指标才有计算基础。对于一颗硬件信任根IP来说FMEDA分析的难点在哪儿呢第一是模块多。密钥生成单元、密钥存储单元、加密引擎、通信接口、寄存器控制逻辑每个模块都要单独分析找出所有潜在的失效点。第二是安全机制要懂行。比如SHA-256哈希引擎里面某个逻辑门的输出被卡在0了靠什么发现可能需要并发计算一个测试向量或者用冗余逻辑做比较。设计这些机制需要极其熟悉密码学和硬件架构不是简单的加个ECC就能糊弄过去的。我们在评估一颗安全IP时会重点看两个数字一个是单点故障度量SPFM它代表芯片中各个已诊断出的故障点占所有故障点的比例另一个是潜在故障度量LFM它反映系统在汽车整个生命周期中能否及时发现那些隐藏的、不会立刻导致失效但会逐渐累积的故障。对于ASIL-BSPFM通常要求大于90%LFM要求大于60%到了ASIL-DSPFM要大于99%LFM要大于90%。从90%到99%看似只差一点点但设计难度是指数级上升的对诊断覆盖率的要求极其苛刻。3.3 IP拿到认证不等于芯片拿到认证集成还有几步路很多从业者容易有一个误解看到某颗安全IP宣传说通过ISO 26262认证就以为用这颗IP的整个SoC也自动满足了功能安全要求。实际上完全不是这么回事。一颗IP的功能安全认证只是证明这个IP本身的设计是符合功能安全流程的并且具备一定的安全机制能力。它集成到SoC里之后SoC整体能否满足某个ASIL等级还需要做系统级的FMEDA和失效分析。打个比方一颗符合功能安全要求的发动机装到某辆汽车上不代表整车就一定符合安全标准还得看整车的设计、装配和调试。IP厂商能提供的是详尽的Safety Manual安全手册告诉集成商这个IP怎么配置、怎么连接、怎么诊断以及哪些使用方式可以满足预期的安全等级。集成商必须严格按照这些约束来做设计在SoC层面再补一轮安全分析和验证才能最终宣称整车芯片的ASIL等级。这就意味着选IP的时候除了看IP本身的技术参数还要看Safety Manual的质量。如果Safety Manual写得含糊其辞安全机制使用条件不清晰后面SoC级认证会非常痛苦。Intrinsic ID这种老牌安全IP公司在文档规范性和客户支持上一般比半导体公司自研的安全IP要成熟这也是他们能从独立IP供应商这个身份切入汽车市场的重要原因。4. 这套方案在整车上的落地场景4.1 安全启动车辆上电那一刻的信任链汽车上电之后第一个执行的是BootROM它一般固化在芯片内部不可修改所以天然可信。但BootROM之后要加载二级引导程序、操作系统、应用程序每一级都需要验证——最直接的证据就是签名。谁来做签名校验必然需要一个存放根密钥的信任源这个根密钥就是整个信任链的起点。如果把根密钥放在普通Flash里攻击者可以通过总线监听、调试接口等方式读取出来从而伪造签名。这就是为什么真实项目中安全启动必须有一个硬件信任根来存放和保护根密钥。PUF方案在这里的优势是根密钥不需要存储在Flash里每次上电由SRAM PUF生成不需要额外的密钥导入过程也不存在密钥泄漏给软件开发团队的风险。在集成层面安全启动还需要考虑性能。车辆启动时间是有严格要求的用户按下一键启动不可能等上十秒才看到仪表盘点亮。签名校验用的公钥运算通常是RSA或ECC如果每次启动都要完整验签对芯片算力也有要求。所以一颗好的信任根IP不仅要保证安全机制的强度还要配合SoC层面做流程优化把验签过程尽量并行化让启动时间和安全性都不妥协。4.2 OTA与车云通信升级过程中的安全底座现在的智能汽车没有OTA几乎没法卖但是OTA也是最容易出问题的环节之一。一颗车辆的固件包被篡改后下发轻则功能故障重则直接危及行车安全。OTA安全的关键不仅是传输通道要加密更重要的是固件包本身的完整性和真实性验证这又回到信任根上来了。PUF还有一个天然适合OTA场景的特性它支持在设备的整个生命周期内动态生成和管理密钥。传统方案中密钥在工厂预置后续如果密钥轮换需要设计复杂的远程密钥更新协议。而PUF方案可以在设备端基于内部生成的指纹通过安全协议从云端管理平台获取新的证书和密钥整个过程不需要在设备端存储任何长期密钥即使云端数据泄露攻击者也无法在物理上克隆出设备的身份。说到车云通信每辆车都会有一个唯一身份凭证这个身份凭证如果被复制就会出现密钥克隆攻击——攻击者可以冒充合法车辆向云端发送指令甚至盗刷车辆的数字权益。PUF的物理不可克隆性让每辆车的身份凭证与芯片硬件强绑定这在源头杜绝了大批量克隆攻击的可能。4.3 数据保护与隐私合规每一辆车都是一个数据源一辆现代汽车每天会产生大量数据位置信息、驾驶习惯、车内语音记录、甚至生物特征。这些数据在车端存储、在云端传输任何一个环节泄露都可能引发隐私合规问题。在车辆端对数据进行加密是车厂必须有的能力而加密的密钥管理离不开安全存储和信任根。PUF方案在数据加密场景还有一个让我很看好的点它支持密钥的用完即走。传统的密钥存储在Flash里只要数据还在密钥就在风险就一直在PUF生成的密钥可以在每次安全会话中重新派生会话结束之后密钥在物理上就消失了。对于数据保留和删除的合规要求这种无静态密钥残留的方式在处理车辆退租、二手车转让、车辆报废这些场景时特别有用。另外一个容易被忽视的点是数据审计。在功能安全体系中如果你是一个车厂的安全工程师你需要能够追踪到每一个安全操作——谁在什么时间用哪个密钥访问了哪些数据。信任根可以为这些日志提供防篡改的时间戳和签名确保审计日志本身不被伪造和篡改。5. 工程化落地避坑指南5.1 选型时建议先想清楚这几个问题我在评估安全IP的时候会先不看参数表而是让产品团队回答几个前提问题。第一个问题是你们的目标产品最终要满足哪个ASIL等级这决定了IP的安全机制需要达到什么水平也直接关系到底层硬件选型和认证投入。第二个问题是你们的SoC生产工艺是什么PUF方案对工艺有一定要求SRAM单元的特性和稳定性需要在具体工艺节点上做特征化测试选择在目标工艺上已经有数据库和参考设计的IP厂商会省很多事。第三个问题是密钥管理体系是怎么设计的PUF虽然不需要存储密钥但它仍然需要一套设备生命周期管理方案包括工厂生产阶段的密钥生成、使用阶段的密钥轮换、售后阶段的设备恢复和注销。这个体系的复杂度经常会超出预期建议在选型阶段就让供应商把完整的生命周期方案拿出来。第四个问题是安全IP与主处理器核的集成方式。如果IP只支持某一种总线接口而你的SoC主总线是另一种协议集成成本和性能损耗都会上升。5.2 集成阶段最容易踩的四个坑先说说PUF相关的温度漂移问题。SRAM PUF生成的指纹虽然每次都相近但不同温度和电压条件下某些SRAM单元的表现可能发生变化。IP里会有纠错模块来应对但纠错能力是有限的。如果在产品规格里没有定义清楚工作温度范围后期在极端温度环境下出现密钥恢复失败的情况排查起来非常费劲。建议在芯片定义阶段就跟IP厂商确认好温度模型和目标工况。第二个坑是生产阶段的密钥测试。很多团队在流片后测试时会把PUF生成的原始指纹直接导出到测试日志里做分析这在开发阶段没问题但量产时如果你不小心在测试日志中记录了完整的PUF指纹那就相当于把密钥写在了包装盒上。量产流程中必须设计专门的测试模式保证PUF的原始数据只能在安全边界内访问。第三个坑是安全机制与功能安全机制的叠加冲突。PUF模块本身可能有自己的诊断机制比如自检和错误监控这些机制与SoC级的安全机制之间如果缺乏协同可能会造成误报或者漏报。例如PUF自检报出一个临时性错误却触发了SoC级的安全状态复位导致整个ECU重启这在功能安全分析中会成为一个需要重点关注的故障场景。第四个坑是向后兼容。很多车厂在做新平台时并不是完全从零开始而是基于已有平台升级。老的软件栈可能已经固化了密钥存储接口的调用方式如果新的硬件方案改成PUF动态生成密钥软件接口就要跟着调整工作量比想象的更大。建议尽早让软件团队介入评估安全中间件的适配成本。5.3 关于PUF和功能安全大家常问的几个问题结合我在项目里被问到最多的几个问题整理成下面这个速查表方便大家快速定位。疑问实际情况与实操建议PUF生成的密钥会不会在高温下失效会有一定影响但IP内部一般都有纠错机制和温度补偿。关键是选型时确认IP在目标温度范围内的误码率和纠错余量不建议只按常温数据评估。如果芯片上PUF单元本身坏了车辆还能正常使用吗芯片是有诊断机制的。如果PUF模块发生永久性故障会触发安全状态或进入恢复流程。这和传统方案的密钥丢失处理逻辑不同PUF方案一般可以重新在片上重新生成并安全恢复密钥。车辆报废之后车里数据怎么彻底清理PUF的特性决定了只要不再生成密钥所有静态加密数据都不可读。相比Flash中存储的密钥数据的不可回收程度更高对隐私合规是优势。这套方案只能用于汽车吗当然不是。PUF技术在物联网、工控、数据中心都是主流方向。汽车市场之所以关注度高是因为功能安全的认证门槛最高一旦在汽车市场验证通过其他领域几乎是无缝复用。首个会不会只是营销噱头从行业惯例看功能安全认证不是营销活动它有严格的工具链、文档和测试审计流程。凭营销话术过不了审核所以这个首个背后是有实际技术投入支撑的。说一个我个人的体会安全芯片这个圈子最怕的不是没有新方案而是新方案在安全性上说得天花乱坠最后倒在了工程化的细枝末节上。功能安全认证的意义在于它强迫设计方把芯片会不会坏、坏了怎么办这个问题从项目第一天就摆上台面而不是等产品交付之后再补作业。这也是为什么看到Intrinsic ID这次发布我更关注的是他们在功能安全上完成的闭环而不只是PUF技术本身的噱头。最后再分享一个小建议如果你所在的项目正在评估类似的安全IP方案不要一上来就纠结于加密算法是AES还是国密SM系列先去看看供应商能不能给你一份完整的FMEDA摘要和Safety Manual。能拿得出这些文档且经得起推敲的才是真正意义上为汽车市场做好了准备的方案。功能安全认证这条路虽然费时费力但它给出的不仅是合规这个结果更是整个团队对产品可靠性认知的一次系统性升级。
汽车行业最近有个动向挺值得琢磨Intrinsic ID 正式发布了面向汽车市场的硬件根信任Hardware Root-of-Trust解决方案而且直接对标功能安全标准Functional Safety Standards来打。消息本身不算长但干这行的都清楚这个首个满足功能安全标准的说法背后搅动的不只是一家公司的产品线而是整个汽车电子安全架构的设计思路。先说为什么这个事值得单拎出来聊。过去几年汽车上越来越多的控制器、传感器、网联模块在往车里塞车已经从一个纯机械产品变成了跑在轮子上的计算平台。计算平台多了攻击面自然就大。随便一辆新车的电子控制单元ECU数量都奔着上百个去再加上OTA升级、V2X通信、自动驾驶域控制器这些新功能信息安全如果只停留在某个模块加个加密芯片这个层面根本兜不住。安全必须是分层、成体系的而体系需要一个能站得住的根基——这就是硬件信任根。然而问题也随之而来信任根本身也是硬件它自己也会老化、会有随机故障、也会在某些极端工况下失效。如果根基自己先垮了整个安全体系等于白搭。这恰好就是功能安全要管的事。所以Intrinsic ID这次的发布本质上是在回答一个之前整个行业都没完全解决的问题怎么让安全的根同时是可靠的根。1. 为什么汽车市场的信任根绕不开功能安全这道门槛1.1 功能安全管的是硬件自己坏了怎么办很多刚接触汽车电子的朋友会把信息安全和功能安全当成一回事其实两个体系关注的问题完全不一样。信息安全防的是有人使坏功能安全防的是自己坏掉。后者在汽车行业有一套专门的标准——ISO 26262它管的是电控系统在发生随机硬件故障、系统性设计失误时能不能把风险控制在可接受的范围内。用大白话讲恶意攻击者想篡改你的刹车信号那是信息安全的问题但刹车控制器自己的一块存储单元因为老化突然写错了数据那是功能安全的问题。这两件事在传统IT领域可以分开处理但在汽车上必须同时考虑因为汽车电控系统的每一个关键操作都直接关联物理运动。方向盘、油门、刹车这些部件的控制器如果出现一个未被发现的硬件故障后果可能比一次网络攻击更直接。硬件信任根在这套逻辑里处于一个特殊位置它是整个安全体系的保险丝。安全启动要依赖它验证固件通信加密要依赖它管理密钥OTA升级要依赖它鉴别固件包。如果信任根自身出现随机故障所有基于它建立的安全能力都会同步失效。这也意味着信任根芯片不能只说自己安全性很强还必须证明自己在故障模式下依然安全这正是功能安全标准的核心诉求。1.2 信息安全与功能安全在车里早就分不开了放在五年前安全团队和功能安全团队在车企里通常是两个部门、两套流程、甚至两家供应商。但现在越来越多项目意识到这两件事在汽车电子架构里根本没法完全切割。举个例子一辆支持OTA的智能汽车云端下发的固件包如果被篡改导致某个ECU的软件逻辑出错最终触发了刹车系统的错误动作。这个事故你说是信息安全问题还是功能安全问题攻击路径是信息安全的但最终后果是功能安全的。所以在最新的行业实践里大家开始强调一条安全链从芯片的信任根出发到启动过程、运行时环境、关键应用再到云端服务每个环节既要考虑抗攻击也要考虑硬件自身的可靠性。这也是为什么Intrinsic ID这款硬件信任根方案要专门去满足功能安全标准。过去汽车芯片厂商选安全IP关注点主要放在能不能防住攻击者上面比如密钥怎么存、算法有多强、有没有防侧信道攻击的能力。但现在的车规项目客户第一句话往往会问这颗IP过了ISO 26262没有有没有ASIL等级FMEDA报告能看吗这个变化很实在因为对于车厂来说一颗安全IP如果本身没有功能安全认证整车的安全论证链条就断了一截后面的审核和备案都会非常痛苦。2. Intrinsic ID的PUF方案凭什么拿下首个2.1 SRAM PUF上电瞬间生成的芯片指纹Intrinsic ID这家公司在安全圈子里向来以物理不可克隆函数PUFPhysically Unclonable Function技术出名这次发布的核心还是他们的老本行SRAM PUF方案。PUF这个技术听起来玄乎原理其实不复杂芯片在制造过程中晶体管之间的微小差异是随机且不可控的即便是同一块晶圆、同一台光刻机生产出来的芯片晶体管之间的阈值电压也会存在细微偏差。这种偏差几乎是无法复制的就像人的指纹。SRAM PUF利用的正是这一特性。SRAM单元在上电的瞬间每个存储单元会随机偏向逻辑0或逻辑1而由于制造偏差的影响某些单元会稳定地偏向0某些单元会稳定地偏向1。这意味着每次给芯片上电读出来的数据其实是一串由物理特性决定的、独一无二的指纹。把这串指纹通过算法加工就能生成可靠的密钥。在我参与的多个安全芯片项目里SRAM PUF最吸引人的一点在于密钥不是存在芯片里的而是每次上电时长出来的。芯片关机后密钥在物理上就消失了下次上电再重新生成。这从根上消灭了密钥被静态提取这个传统安全芯片最头疼的问题。如果攻击者用探针手段去读取存储介质会发现根本没有完整的密钥可以偷。2.2 对比eFuse和SEPUF在成本和可靠性上的优势在Intrinsic ID方案出现之前汽车安全芯片常用的密钥存储方案主要有两种一种是在片上集成一次性可编程存储eFuse/OTP把密钥在出厂前烧录进去另一种是外挂一颗独立的安全芯片SE或者HSM专门负责密钥存储和加密运算。这两种方案都有各自的软肋。eFuse的优点是简单直接但密钥一旦烧录进去就是静态的总线读取、功耗分析、故障注入攻击都有可能把密钥扒出来。而且eFuse在车规场景下还有一个实际痛点它需要额外的编程电压和高压晶体管不但增加了芯片面积高压电路本身在寿命周期内的可靠性也更难论证。对于ISO 26262来说多一个高压模块就多一堆失效模式需要分析认证成本居高不下。独立SE芯片的方案安全性更高但成本也高。一颗合规的车规级SE芯片可能要额外增加好几美元BOM成本还要占一块PCB面积。更麻烦的是SE芯片自身也有密钥管理问题——它自己的根密钥怎么保护最后一层密钥总会落到某个静态存储介质里这只是把问题转移了。PUF则用另一种思路绕开了这个死结密钥不存在静态存储里每次上电重新生成攻击者没有秘钥存储这个固定的攻击目标。同时SRAM在车规芯片里是极其成熟的标准单元没有高压、没有特殊工艺可靠性数据积累充分这对后续的功能安全认证是巨大的加分项。2.3 一个IP要满足功能安全实际做了哪些事这次Intrinsic ID能说自己是首个满足功能安全标准的硬件根信任方案不是请个检测机构来做个简单测试就行的。根据行业内功能安全认证的一般流程一颗安全IP要做到这一点至少要完成以下几类工作首先要对IP内部所有功能模块做FMEDA分析把每一个模块可能出现的失效模式都列出来比如寄存器位翻转、状态机卡死、总线错误逐一分析失效的影响和可检测性其次要设计相应的安全机制比如错误纠正码ECC、双核锁步、CRC校验、内置自测BIST等最后要进行完整的失效注入测试用模拟方式验证安全机制确实能在故障发生时把系统带到安全状态。这套流程做下来工作量相当大。尤其是PUF相关的模块其密钥生成过程涉及模拟电路特性失效分析比纯粹的数字逻辑更复杂。温度漂移、电压波动、器件老化都会影响SRAM单元的稳定性。Intrinsic ID之所以能率先做到说明他们在车规领域至少已经积累了好几年不可能是临时起意。而且需要注意的是交付的功能安全文档包不是一次性的IP更新一个版本所有安全分析都要跟着重新做这是个持续投入很大的方向。3. ISO 26262认证对一颗安全IP意味着什么3.1 先搞清楚ASIL等级从A到D差异有多大ISO 26262把汽车安全完整性等级分成了A、B、C、D四个等级D最严格。怎么理解这个等级它不是一个简单的评分而是跟可接受的风险概率挂钩的。ASIL等级越高系统可以容忍的失效概率就越低。如果某个系统被定级为ASIL-D那么它平均每小时的危险失效概率要低于一个极小的阈值折算下来相关硬件单点失效的指标要求也极为苛刻。在整车里并不是所有系统都需要ASIL-D。比如转向、制动这类直接影响车辆可控性的系统通常要求ASIL-D而一些信息娱乐、车载导航这类故障不会直接造成人身伤害的系统可能ASIL-A就够了。硬件信任根比较特殊它的客户是整车上几乎所有的ECU——安全启动、关键数据存储、通信认证都用到它。所以它最好能支持到尽可能高的等级至少得覆盖ASIL-B以上才能满足多数功能域的需求。还有一种理解方式ASIL等级像是一条可靠性承诺线。一颗IP声称支持ASIL-D意味着它提供的每一个安全机制都经过了严格分析目标失效概率极低故障自我诊断能力极强。这跟这颗芯片质量不错完全不在一个层次上。后者是产品质量问题前者是整个开发流程和验证深度的系统性问题。3.2 FMEDA背后安全指标是用数字说话的功能安全认证里最核心的一份文档叫FMEDAFailure Modes, Effects and Diagnostic Analysis简单说就是把芯片里每个模块可能怎么坏、坏了对系统有什么影响、靠什么机制发现这种故障全部列成一张大表逐项分析。有了这张表后续的SPFM单点故障度量、LFM潜在故障度量和FIT单位时间失效数这些指标才有计算基础。对于一颗硬件信任根IP来说FMEDA分析的难点在哪儿呢第一是模块多。密钥生成单元、密钥存储单元、加密引擎、通信接口、寄存器控制逻辑每个模块都要单独分析找出所有潜在的失效点。第二是安全机制要懂行。比如SHA-256哈希引擎里面某个逻辑门的输出被卡在0了靠什么发现可能需要并发计算一个测试向量或者用冗余逻辑做比较。设计这些机制需要极其熟悉密码学和硬件架构不是简单的加个ECC就能糊弄过去的。我们在评估一颗安全IP时会重点看两个数字一个是单点故障度量SPFM它代表芯片中各个已诊断出的故障点占所有故障点的比例另一个是潜在故障度量LFM它反映系统在汽车整个生命周期中能否及时发现那些隐藏的、不会立刻导致失效但会逐渐累积的故障。对于ASIL-BSPFM通常要求大于90%LFM要求大于60%到了ASIL-DSPFM要大于99%LFM要大于90%。从90%到99%看似只差一点点但设计难度是指数级上升的对诊断覆盖率的要求极其苛刻。3.3 IP拿到认证不等于芯片拿到认证集成还有几步路很多从业者容易有一个误解看到某颗安全IP宣传说通过ISO 26262认证就以为用这颗IP的整个SoC也自动满足了功能安全要求。实际上完全不是这么回事。一颗IP的功能安全认证只是证明这个IP本身的设计是符合功能安全流程的并且具备一定的安全机制能力。它集成到SoC里之后SoC整体能否满足某个ASIL等级还需要做系统级的FMEDA和失效分析。打个比方一颗符合功能安全要求的发动机装到某辆汽车上不代表整车就一定符合安全标准还得看整车的设计、装配和调试。IP厂商能提供的是详尽的Safety Manual安全手册告诉集成商这个IP怎么配置、怎么连接、怎么诊断以及哪些使用方式可以满足预期的安全等级。集成商必须严格按照这些约束来做设计在SoC层面再补一轮安全分析和验证才能最终宣称整车芯片的ASIL等级。这就意味着选IP的时候除了看IP本身的技术参数还要看Safety Manual的质量。如果Safety Manual写得含糊其辞安全机制使用条件不清晰后面SoC级认证会非常痛苦。Intrinsic ID这种老牌安全IP公司在文档规范性和客户支持上一般比半导体公司自研的安全IP要成熟这也是他们能从独立IP供应商这个身份切入汽车市场的重要原因。4. 这套方案在整车上的落地场景4.1 安全启动车辆上电那一刻的信任链汽车上电之后第一个执行的是BootROM它一般固化在芯片内部不可修改所以天然可信。但BootROM之后要加载二级引导程序、操作系统、应用程序每一级都需要验证——最直接的证据就是签名。谁来做签名校验必然需要一个存放根密钥的信任源这个根密钥就是整个信任链的起点。如果把根密钥放在普通Flash里攻击者可以通过总线监听、调试接口等方式读取出来从而伪造签名。这就是为什么真实项目中安全启动必须有一个硬件信任根来存放和保护根密钥。PUF方案在这里的优势是根密钥不需要存储在Flash里每次上电由SRAM PUF生成不需要额外的密钥导入过程也不存在密钥泄漏给软件开发团队的风险。在集成层面安全启动还需要考虑性能。车辆启动时间是有严格要求的用户按下一键启动不可能等上十秒才看到仪表盘点亮。签名校验用的公钥运算通常是RSA或ECC如果每次启动都要完整验签对芯片算力也有要求。所以一颗好的信任根IP不仅要保证安全机制的强度还要配合SoC层面做流程优化把验签过程尽量并行化让启动时间和安全性都不妥协。4.2 OTA与车云通信升级过程中的安全底座现在的智能汽车没有OTA几乎没法卖但是OTA也是最容易出问题的环节之一。一颗车辆的固件包被篡改后下发轻则功能故障重则直接危及行车安全。OTA安全的关键不仅是传输通道要加密更重要的是固件包本身的完整性和真实性验证这又回到信任根上来了。PUF还有一个天然适合OTA场景的特性它支持在设备的整个生命周期内动态生成和管理密钥。传统方案中密钥在工厂预置后续如果密钥轮换需要设计复杂的远程密钥更新协议。而PUF方案可以在设备端基于内部生成的指纹通过安全协议从云端管理平台获取新的证书和密钥整个过程不需要在设备端存储任何长期密钥即使云端数据泄露攻击者也无法在物理上克隆出设备的身份。说到车云通信每辆车都会有一个唯一身份凭证这个身份凭证如果被复制就会出现密钥克隆攻击——攻击者可以冒充合法车辆向云端发送指令甚至盗刷车辆的数字权益。PUF的物理不可克隆性让每辆车的身份凭证与芯片硬件强绑定这在源头杜绝了大批量克隆攻击的可能。4.3 数据保护与隐私合规每一辆车都是一个数据源一辆现代汽车每天会产生大量数据位置信息、驾驶习惯、车内语音记录、甚至生物特征。这些数据在车端存储、在云端传输任何一个环节泄露都可能引发隐私合规问题。在车辆端对数据进行加密是车厂必须有的能力而加密的密钥管理离不开安全存储和信任根。PUF方案在数据加密场景还有一个让我很看好的点它支持密钥的用完即走。传统的密钥存储在Flash里只要数据还在密钥就在风险就一直在PUF生成的密钥可以在每次安全会话中重新派生会话结束之后密钥在物理上就消失了。对于数据保留和删除的合规要求这种无静态密钥残留的方式在处理车辆退租、二手车转让、车辆报废这些场景时特别有用。另外一个容易被忽视的点是数据审计。在功能安全体系中如果你是一个车厂的安全工程师你需要能够追踪到每一个安全操作——谁在什么时间用哪个密钥访问了哪些数据。信任根可以为这些日志提供防篡改的时间戳和签名确保审计日志本身不被伪造和篡改。5. 工程化落地避坑指南5.1 选型时建议先想清楚这几个问题我在评估安全IP的时候会先不看参数表而是让产品团队回答几个前提问题。第一个问题是你们的目标产品最终要满足哪个ASIL等级这决定了IP的安全机制需要达到什么水平也直接关系到底层硬件选型和认证投入。第二个问题是你们的SoC生产工艺是什么PUF方案对工艺有一定要求SRAM单元的特性和稳定性需要在具体工艺节点上做特征化测试选择在目标工艺上已经有数据库和参考设计的IP厂商会省很多事。第三个问题是密钥管理体系是怎么设计的PUF虽然不需要存储密钥但它仍然需要一套设备生命周期管理方案包括工厂生产阶段的密钥生成、使用阶段的密钥轮换、售后阶段的设备恢复和注销。这个体系的复杂度经常会超出预期建议在选型阶段就让供应商把完整的生命周期方案拿出来。第四个问题是安全IP与主处理器核的集成方式。如果IP只支持某一种总线接口而你的SoC主总线是另一种协议集成成本和性能损耗都会上升。5.2 集成阶段最容易踩的四个坑先说说PUF相关的温度漂移问题。SRAM PUF生成的指纹虽然每次都相近但不同温度和电压条件下某些SRAM单元的表现可能发生变化。IP里会有纠错模块来应对但纠错能力是有限的。如果在产品规格里没有定义清楚工作温度范围后期在极端温度环境下出现密钥恢复失败的情况排查起来非常费劲。建议在芯片定义阶段就跟IP厂商确认好温度模型和目标工况。第二个坑是生产阶段的密钥测试。很多团队在流片后测试时会把PUF生成的原始指纹直接导出到测试日志里做分析这在开发阶段没问题但量产时如果你不小心在测试日志中记录了完整的PUF指纹那就相当于把密钥写在了包装盒上。量产流程中必须设计专门的测试模式保证PUF的原始数据只能在安全边界内访问。第三个坑是安全机制与功能安全机制的叠加冲突。PUF模块本身可能有自己的诊断机制比如自检和错误监控这些机制与SoC级的安全机制之间如果缺乏协同可能会造成误报或者漏报。例如PUF自检报出一个临时性错误却触发了SoC级的安全状态复位导致整个ECU重启这在功能安全分析中会成为一个需要重点关注的故障场景。第四个坑是向后兼容。很多车厂在做新平台时并不是完全从零开始而是基于已有平台升级。老的软件栈可能已经固化了密钥存储接口的调用方式如果新的硬件方案改成PUF动态生成密钥软件接口就要跟着调整工作量比想象的更大。建议尽早让软件团队介入评估安全中间件的适配成本。5.3 关于PUF和功能安全大家常问的几个问题结合我在项目里被问到最多的几个问题整理成下面这个速查表方便大家快速定位。疑问实际情况与实操建议PUF生成的密钥会不会在高温下失效会有一定影响但IP内部一般都有纠错机制和温度补偿。关键是选型时确认IP在目标温度范围内的误码率和纠错余量不建议只按常温数据评估。如果芯片上PUF单元本身坏了车辆还能正常使用吗芯片是有诊断机制的。如果PUF模块发生永久性故障会触发安全状态或进入恢复流程。这和传统方案的密钥丢失处理逻辑不同PUF方案一般可以重新在片上重新生成并安全恢复密钥。车辆报废之后车里数据怎么彻底清理PUF的特性决定了只要不再生成密钥所有静态加密数据都不可读。相比Flash中存储的密钥数据的不可回收程度更高对隐私合规是优势。这套方案只能用于汽车吗当然不是。PUF技术在物联网、工控、数据中心都是主流方向。汽车市场之所以关注度高是因为功能安全的认证门槛最高一旦在汽车市场验证通过其他领域几乎是无缝复用。首个会不会只是营销噱头从行业惯例看功能安全认证不是营销活动它有严格的工具链、文档和测试审计流程。凭营销话术过不了审核所以这个首个背后是有实际技术投入支撑的。说一个我个人的体会安全芯片这个圈子最怕的不是没有新方案而是新方案在安全性上说得天花乱坠最后倒在了工程化的细枝末节上。功能安全认证的意义在于它强迫设计方把芯片会不会坏、坏了怎么办这个问题从项目第一天就摆上台面而不是等产品交付之后再补作业。这也是为什么看到Intrinsic ID这次发布我更关注的是他们在功能安全上完成的闭环而不只是PUF技术本身的噱头。最后再分享一个小建议如果你所在的项目正在评估类似的安全IP方案不要一上来就纠结于加密算法是AES还是国密SM系列先去看看供应商能不能给你一份完整的FMEDA摘要和Safety Manual。能拿得出这些文档且经得起推敲的才是真正意义上为汽车市场做好了准备的方案。功能安全认证这条路虽然费时费力但它给出的不仅是合规这个结果更是整个团队对产品可靠性认知的一次系统性升级。
