1. 从一颗MCU的异常复位说起功能安全与信息安全到底在防什么前阵子帮一个做工业控制的朋友排查问题他们的板子在现场跑了三个月偶尔会出现电机误动作。查了一圈硬件没找到毛病最后定位到一颗负责采集电流的MCU上——它的ADC采样值在特定温度下会跳变而固件里没有任何校验逻辑跳变值直接被当成真实电流送进了控制环路。这件事的本质不是硬件坏了而是这颗芯片在“功能安全”上留了缺口它没有能力证明自己给出的数据是可信的。几乎同一时间另一个做消费电子的团队遇到的是另一类问题他们的设备被人在调试口上读出了完整固件密钥直接暴露。这是“信息安全”的缺口——芯片没有守住自己的秘密。这两个案例放在一起正好对应了标题里的两个词。功能安全Functional Safety常缩写为FuSa关心的是“芯片会不会因为自身故障而做出危险动作”核心目标是避免随机硬件失效和系统性失效导致的人身或财产伤害。信息安全Information Security常缩写为InfoSec或Cyber Security关心的是“芯片会不会被外部恶意利用”核心目标是保证机密性、完整性、可用性。两者经常被混为一谈但它们的出发点、方法论、验证手段完全不同甚至在资源分配上还会互相打架。这篇文章面向的是做嵌入式、汽车电子、工业控制、医疗电子这类对可靠性有要求的工程师也适合刚接触这两个概念、想搞清楚“到底该怎么落地”的开发者。我会从标准体系讲到芯片内部的具体机制再落到实际项目里怎么选型、怎么配置、怎么验证尽量把那些文档里不会写的坑都摊开说。2. 功能安全与信息安全的标准体系与底层逻辑2.1 功能安全从IEC 61508到ISO 26262的演进脉络功能安全不是某个厂商拍脑袋定的它有一整套国际标准撑着。最底层的是IEC 61508这是功能安全的“母标准”定义了安全完整性等级SIL 1~4适用于所有电气/电子/可编程电子安全相关系统。汽车行业在此基础上派生出了ISO 26262把安全完整性等级改叫ASILA~D其中ASIL D要求最严。工业领域有IEC 61511医疗有IEC 62304轨道交通有EN 50128。这些标准的核心思路是一致的先做危害分析与风险评估HARA确定每个安全目标需要达到的完整性等级然后把这个等级分解到硬件和软件上最后用诊断覆盖率Diagnostic Coverage和安全失效分数Safe Failure Fraction来量化验证。我拿ISO 26262举个例子。假设一个电子助力转向系统HARA分析后发现“转向助力突然消失”这个危害的严重度是S3、暴露率是E4、可控性是C3查表得到ASIL D。这意味着整个信号链——从传感器到MCU到执行器——都必须满足ASIL D的要求。对MCU来说ASIL D意味着单点故障度量SPFM要≥99%潜伏故障度量LFM要≥90%。这两个数字不是随便写的它们直接决定了芯片内部要放多少自检电路。注意很多新手会以为“买了ASIL D的芯片就等于系统达到了ASIL D”这是错的。芯片只是整个安全链路的一环系统级的安全论证还需要考虑PCB、电源、外部器件、软件架构等。芯片的ASIL等级只是给你提供了一个可用的“积木”。2.2 信息安全从通用加密到行业专用的分层防护信息安全的标准体系更分散一些。通用层面有ISO/IEC 27001信息安全管理体系、Common CriteriaCC信息技术安全评估准则。汽车行业有ISO/SAE 21434定义了车辆全生命周期的网络安全工程要求。工业领域有IEC 62443芯片层面还有SESIPSecurity Evaluation Standard for IoT Platforms和PSA Certified。信息安全的底层逻辑和功能安全不同。功能安全是“防自己坏”信息安全是“防别人坏”。所以信息安全的机制围绕几个核心目标展开身份认证确认通信对方是谁、数据加密防止被窃听、完整性校验防止被篡改、安全启动防止运行未授权固件、安全存储防止密钥被读出。在芯片层面这些目标通常由硬件安全模块HSM、可信执行环境TEE、物理不可克隆函数PUF、真随机数发生器TRNG等模块来实现。和功能安全不同信息安全没有“ASIL D”这种一刀切的等级而是根据攻击面和攻击可行性来分层设计。一个智能门锁的芯片和一个自动驾驶域控制器的芯片安全需求天差地别。2.3 两者的冲突与协同资源、验证与设计哲学功能安全和信息安全在芯片设计里经常抢资源。功能安全要求确定性——同样的输入必须产生同样的输出所以它倾向于用冗余、锁步、ECC这些“笨重但可靠”的机制。信息安全要求随机性——加密算法需要真随机数密钥需要不可预测所以它倾向于用TRNG、PUF这些“不可复现”的机制。更麻烦的是验证方法。功能安全的验证靠故障注入Fault Injection——人为地在芯片里制造位翻转看安全机制能不能检测到。信息安全的验证靠渗透测试——模拟攻击者看能不能绕过防护。这两种验证在实验室里经常互相干扰故障注入可能触发安全模块的防篡改机制渗透测试可能被功能安全的自检逻辑误判为异常。实际项目里我的经验是先做功能安全再做信息安全。因为功能安全是基础——如果芯片连自己的计算是否正确都保证不了谈何保护密钥但到了集成阶段两者必须一起做联合验证尤其是共享资源如总线、内存、时钟的访问冲突要重点排查。3. 芯片内部的功能安全机制从锁步核到总线ECC3.1 锁步核与冗余执行最直接但也最贵的方案锁步核Lockstep Core是功能安全里最广为人知的机制。原理很简单两个相同的CPU核跑同样的代码每个时钟周期比较它们的输出一旦不一致就触发错误信号。有些实现是物理上两个核有些是同一个核延迟几个周期执行时域冗余。锁步核的优点是诊断覆盖率极高对CPU内部的瞬态故障几乎能做到100%检测。但代价也明显面积翻倍、功耗增加、成本上升。所以很多芯片只在安全关键路径上用锁步比如刹车控制、安全气囊触发而信息娱乐系统就用普通核。我在一个工业项目里用过某款带锁步核的MCU实测下来发现一个坑锁步比较器本身也可能失效。如果比较器坏了两个核不一致它也不报错那就等于没有保护。所以高等级的芯片会在比较器上再加一层自检定期注入一个已知的错误看比较器能不能抓到。这个细节在数据手册里通常不会写得去翻安全手册Safety Manual。3.2 存储器保护ECC、CRC与MBIST的分工存储器是芯片里最容易出软错误Soft Error的地方。宇宙射线、电磁干扰都可能导致存储单元里的位翻转。功能安全对存储器的保护通常分三层第一层是ECCError Correcting Code。SRAM和Flash里每写一个数据字同时写入校验位。读的时候如果发现一位错ECC自动纠正如果发现两位错报不可纠正错误。常见的ECC配置是SECDEDSingle Error Correction, Double Error Detection即能纠一位、检两位。第二层是CRCCyclic Redundancy Check。用于保护通信总线上的数据传输比如SPI、CAN、以太网。CRC只能检错不能纠错但实现简单、开销小。选CRC多项式的时候要注意不同的多项式对不同类型的错误检测能力不同。比如CRC-32对突发错误的检测能力就比CRC-16强。第三层是MBISTMemory Built-In Self-Test。这是上电自检的一部分用算法遍历存储器的每个单元检测固定型故障Stuck-at Fault和耦合故障。MBIST通常在启动时跑一次耗时从几毫秒到几百毫秒不等取决于存储器大小。实操心得ECC的纠错能力是有上限的。如果同一个字里出现三位错SECDED就无能为力了。所以在高辐射环境如航天、核工业里会用更复杂的ECC如能纠两位的DEC或者定期做存储器擦洗Memory Scrubbing。擦洗就是定期读出所有存储单元发现可纠正错误就写回修正值防止错误累积。3.3 时钟与电源监控那些容易被忽略的“基础设施”CPU和存储器保护做得再好如果时钟停了或者电压掉了一切白搭。所以功能安全芯片里一定有时钟监控和电源监控。时钟监控通常用独立看门狗Independent Watchdog加时钟失效检测Clock Failure Detection。独立看门狗用一个独立的低速时钟源如内部RC振荡器计时主时钟如果停了看门狗超时就会复位芯片。时钟失效检测则是比较两个时钟源的频率偏差超过阈值就报警。电源监控包括欠压检测Under-Voltage Detection和过压检测Over-Voltage Detection。欠压是最危险的因为电压不够的时候CPU可能执行乱码。好的电源监控会在电压跌到CPU最低工作电压之前就触发复位留出足够的余量。这个余量叫保持时间Hold Time通常要求至少几个微秒。我踩过一个坑某款芯片的欠压阈值设得太低结果电源缓慢下降的时候CPU先乱跑了几百微秒才复位导致一个安全输出被误触发。后来换了阈值更高的芯片并且在软件里加了电源电压的ADC采样双保险才解决。3.4 总线与互连保护End-to-End Protection芯片内部的总线如AXI、AHB连接着CPU、内存、外设。如果总线上的数据被干扰了CPU可能读到错误的外设状态。功能安全对总线的保护叫端到端保护End-to-End ProtectionE2E。E2E的实现方式是在发送端给数据加一个保护码通常是CRC或ECC接收端校验。如果校验失败接收端要么丢弃数据要么触发错误处理。E2E的关键是保护要覆盖整个路径包括总线本身、桥接器、以及外设的寄存器。有些芯片只在总线上做ECC但外设寄存器没有保护。这时候如果寄存器被干扰CPU读到的就是错误值。所以高等级芯片会在外设寄存器上也加ECC或者奇偶校验。选型的时候一定要看安全手册里E2E的覆盖范围别只看宣传页上的“支持ECC”。4. 芯片内部的信息安全机制从安全启动到侧信道防护4.1 安全启动信任链的起点安全启动Secure Boot是信息安全的基石。它的逻辑是芯片上电后先运行一段不可修改的引导ROMBoot ROM这段ROM用芯片内固化的公钥验证下一级引导程序的签名。验证通过才跳转不通过就停在安全状态或者进入恢复模式。信任链就这样一级一级传下去Boot ROM验证BootloaderBootloader验证操作系统操作系统验证应用。每一级都用自己的私钥签名下一级用对应的公钥验证。公钥存在芯片的一次性可编程存储器OTP里写完就改不了。安全启动的难点不在密码学而在密钥管理。私钥怎么生成、怎么存储、怎么吊销这些流程问题比技术问题更容易出事。我见过一个团队把私钥放在Git仓库里结果仓库被泄露整个信任链崩塌。正确的做法是用硬件安全模块HSM生成和存储私钥签名操作在HSM内部完成私钥永远不出HSM。4.2 硬件安全模块芯片里的“保险柜”HSM是芯片里专门负责安全运算的独立子系统。它有自己的CPU、内存、加密加速器、真随机数发生器和主系统物理隔离。主系统要加密数据就把数据发给HSMHSM算完把结果返回密钥全程不离开HSM。HSM的核心能力包括AES对称加密、RSA/ECC非对称加密、SHA哈希、TRNG真随机数、安全存储密钥槽。高级的HSM还有防篡改检测——如果检测到电压异常、温度异常、光照异常自动擦除密钥。选HSM的时候要注意认证等级。常见的认证有FIPS 140-2/3和Common Criteria EAL。FIPS 140-3的Level 3要求防篡改和身份认证Level 4还要求防环境攻击。汽车行业通常要求HSM达到EVITA Full或EVITA Medium前者支持非对称加密后者只支持对称加密。注意HSM不是万能的。如果主系统被攻破攻击者可以调用HSM的接口来加密自己的数据或者发起拒绝服务攻击让HSM忙不过来。所以HSM的接口要有访问控制和速率限制不能谁都能随便调。4.3 物理不可克隆函数与真随机数信任的“种子”PUFPhysical Unclonable Function利用芯片制造过程中不可避免的微观差异如晶体管阈值电压的随机波动来生成唯一的密钥。每个芯片的PUF输出都不同而且不可预测、不可复制。PUF的好处是密钥不存储——每次需要的时候现场生成断电就消失攻击者拿不到。TRNGTrue Random Number Generator则是利用物理噪声源如热噪声、环形振荡器的抖动生成真随机数。加密算法里的密钥、初始化向量、挑战值都需要真随机数。伪随机数发生器PRNG如果种子被猜到整个加密体系就废了。PUF和TRNG经常配合使用PUF生成根密钥TRNG生成会话密钥。根密钥永远不出芯片会话密钥用完就丢。这样即使某次通信被破解也不会影响其他会话。4.4 侧信道防护当攻击者“看”你的功耗侧信道攻击Side-Channel Attack是信息安全里比较高级的威胁。攻击者不直接破解算法而是测量芯片的功耗、电磁辐射、执行时间通过统计分析反推出密钥。比如AES的S盒操作不同的输入会导致不同的功耗模式攻击者收集大量功耗曲线就能恢复密钥。防护侧信道攻击的手段包括掩码Masking——把敏感数据拆成多个随机份额单独看每一份都无意义隐藏Hiding——让功耗曲线和数据的相关性降低比如随机插入空操作、双轨逻辑恒定时间Constant-Time——保证执行时间不依赖敏感数据。侧信道防护会显著增加芯片的面积和功耗所以通常只在安全等级要求高的场景如金融IC卡、车规安全芯片里用。消费类芯片如果只是防固件读取一般不做侧信道防护。5. 实操落地从选型到验证的完整流程5.1 需求分析先搞清楚你要防什么选型之前必须先做需求分析。功能安全这边先做HARA确定ASIL等级或SIL等级。信息安全这边先做威胁分析与风险评估TARA确定需要防护的攻击面和攻击可行性。TARA的输出通常是一个安全目标列表比如“防止固件被读取”、“防止通信被篡改”、“防止密钥被提取”。每个目标对应一个安全等级比如“高”、“中”、“低”。然后根据安全等级去选芯片而不是反过来。我见过很多团队先选了一款便宜的芯片然后发现安全需求满足不了再换芯片浪费几个月。正确的顺序是需求→标准→芯片→系统设计。5.2 芯片选型看安全手册而不是宣传页选芯片的时候功能安全要看安全手册Safety Manual和安全分析报告Safety Analysis Report。安全手册里会写清楚芯片支持哪些安全机制、诊断覆盖率是多少、有哪些假设条件Assumption of Use。假设条件特别重要——如果系统设计不满足这些假设芯片的安全机制可能失效。信息安全要看安全目标文档Security Target和认证证书。安全目标文档里会写清楚芯片防哪些攻击、不防哪些攻击、安全功能怎么配置。认证证书要看是哪个机构发的、什么等级、覆盖哪些版本。实操心得芯片的勘误表Errata Sheet一定要看。有些安全机制在特定版本里有bug勘误表里会写规避方法。我遇到过一次某款芯片的ECC在特定温度下会误报勘误表里建议关闭ECC的某一位检测但这样会降低诊断覆盖率。最后只能换芯片。5.3 系统集成安全机制不是孤岛芯片选好了集成的时候要注意安全机制的端到端覆盖。比如安全启动只保护了启动过程运行时的固件完整性还需要运行时完整性校验Runtime Integrity Check。通信加密只保护了传输存储加密还需要存储加密Storage Encryption。功能安全这边芯片的自检机制要和系统的安全状态Safe State对接。比如芯片检测到不可纠正错误要能触发系统进入安全状态——可能是关闭输出、切换到备用通道、或者报警。这个对接逻辑要在软件里明确实现不能指望芯片自动搞定。5.4 验证与认证故障注入与渗透测试功能安全的验证靠故障注入。方法有硬件故障注入用激光、电磁脉冲、电压毛刺、软件故障注入修改寄存器值、翻转内存位、仿真故障注入在RTL仿真里强制信号翻转。故障注入的目的是验证安全机制能不能在故障发生时正确响应。信息安全的验证靠渗透测试。包括固件提取看能不能读出Flash、调试口攻击看JTAG/SWD有没有锁、通信劫持看能不能中间人攻击、侧信道分析看功耗曲线有没有泄露。渗透测试最好找第三方团队做自己人容易有盲区。认证方面功能安全通常需要第三方评估机构出具证书信息安全需要Common Criteria或FIPS认证。认证周期长、费用高要提前规划。6. 常见问题与排查技巧实录6.1 功能安全常见问题速查表问题现象可能原因排查方法解决方案芯片频繁复位看门狗超时检查看门狗喂狗周期调整喂狗周期或关闭看门狗调试ECC报不可纠正错误存储器位翻转读错误地址和ECC状态寄存器擦洗存储器或更换芯片锁步核报错两核输出不一致检查比较器日志确认是否瞬态故障必要时复位时钟失效报警主时钟停振测量时钟输出引脚检查晶振电路或切换备用时钟欠压复位电源跌落用示波器抓电源波形增加滤波电容或调整欠压阈值6.2 信息安全常见问题速查表问题现象可能原因排查方法解决方案安全启动失败签名不匹配检查公钥和签名算法重新签名或更新公钥HSM无响应接口被锁检查HSM状态寄存器复位HSM或检查访问权限密钥读取失败密钥槽未初始化检查OTP是否已烧写烧写密钥或使用默认密钥通信解密失败密钥不一致检查双方密钥派生流程统一密钥派生算法和参数随机数质量差TRNG未就绪检查TRNG状态位等待TRNG就绪或增加熵源6.3 独家避坑技巧技巧一功能安全的诊断覆盖率不是越高越好。诊断覆盖率越高芯片越复杂成本越高而且可能引入新的失效模式。关键是匹配需求——ASIL B不需要ASIL D的覆盖率。过度设计是浪费。技巧二信息安全的密钥要定期轮换。很多团队把密钥烧进去就不管了一用就是好几年。密钥用久了泄露风险增加而且一旦泄露影响范围大。建议至少每年轮换一次或者按使用次数轮换。技巧三功能安全和信息安全的测试要分开做但问题要一起看。我遇到过一次功能安全的故障注入触发了信息安全的安全启动回滚导致设备变砖。后来在测试流程里加了联合测试才避免。技巧四芯片的安全手册要逐条对照系统设计。安全手册里的“假设条件”是芯片正常工作的前提。如果系统设计不满足芯片的安全机制可能完全失效。我见过一个项目安全手册要求电源纹波小于50mV但实际电源纹波有200mV结果芯片的欠压检测频繁误触发。技巧五不要忽略PCB级的安全。芯片再安全如果PCB上的调试口没锁、电源没滤波、时钟线没屏蔽攻击者照样能攻破。PCB设计阶段就要考虑安全比如调试口加锁、敏感信号走内层、电源加TVS管。7. 一个虚拟项目的完整落地记录假设我们要做一个工业电机控制器安全等级要求SIL 2信息安全要求防固件读取和通信篡改。以下是我们的落地过程。第一步需求分析。HARA分析后确定SIL 2意味着单点故障度量≥90%潜伏故障度量≥60%。TARA分析后确定两个安全目标固件机密性高、通信完整性中。第二步芯片选型。选了一款带锁步核、ECC、独立看门狗、HSM的MCU。安全手册确认支持SIL 2HSM支持AES-128和SHA-256。勘误表里有一条锁步核在低温下可能误报规避方法是启动时做一次自检。第三步系统设计。功能安全方面锁步核保护CPUECC保护SRAM和Flash独立看门狗监控时钟欠压检测监控电源。信息安全方面安全启动保护固件HSM保护密钥AES加密通信CRC校验数据完整性。第四步软件实现。启动时先跑MBIST和锁步自检然后安全启动验证固件签名。运行时定期做ECC擦洗和看门狗喂狗。通信时用HSM做AES加密和CRC校验。第五步验证。功能安全用软件故障注入翻转SRAM位看ECC能不能检测到。信息安全用渗透测试尝试通过调试口读固件确认调试口已锁。联合测试时模拟电源跌落确认系统能进入安全状态且不泄露密钥。第六步认证。找第三方机构做SIL 2认证和Common Criteria EAL4认证。认证过程中发现一个问题HSM的密钥槽没有防篡改检测不符合EAL4要求。后来换了带防篡改检测的HSM版本才通过。这个项目从需求到认证花了大约18个月其中认证占了6个月。最大的体会是安全设计要趁早后期补安全机制的成本是前期的十倍。8. 一些个人体会功能安全和信息安全在芯片层面的落地说到底是一个权衡的过程。功能安全要确定性信息安全要随机性功能安全要冗余信息安全要隔离功能安全要可验证信息安全要不可预测。这些矛盾没有标准答案只能根据具体场景去平衡。我的经验是先满足功能安全再叠加信息安全。因为功能安全是基础——如果芯片连自己的计算是否正确都保证不了谈何保护密钥但到了集成阶段两者必须一起做联合验证尤其是共享资源的访问冲突要重点排查。另外不要迷信认证。认证只是门槛不是终点。通过认证不代表芯片在实际攻击下一定安全也不代表系统一定可靠。真正的安全是靠持续的监控、更新和响应来维持的。最后分享一个小技巧建立安全需求追溯矩阵。把每一条安全需求映射到具体的芯片机制、软件实现、测试用例。这样在认证和审计的时候能快速证明每一条需求都被覆盖了。这个矩阵在项目后期改需求的时候特别有用能一眼看出改动会影响哪些部分。