做了这么多年嵌入式安全相关的开发我最怕听到一句话“我们的产品已经加了AES加密很安全了。”绝大多数时候这个判断和现实差着十万八千里。嵌入式系统安全不是某一个算法的功劳而是一条从芯片上电第一条指令到业务应用每一行代码的信任链。这条链上任何一个环节断了——比如调试口没锁、信任根被绕过、总线安全属性和实际内存映射对不上——攻击者就能顺着链条摸到你的密钥或者干脆替换你的固件。这篇文章我会结合几个实际方向来聊安全启动、TrustZone与AXI非安全使能、调试口的攻防、嵌入式TLS/SSH的证书坑、Web管理界面的安全源问题以及安全机制在资源受限设备上的取舍。没有太多花哨理论尽量都是可以直接拿到板子上验证的东西。1. 别把“嵌入式安全”做成密码学表演1.1 先搞清楚攻击者在哪再谈保护什么嵌入式系统安全设计的第一步不是选芯片、选加密算法而是先回答三个问题你的资产是什么攻击者能物理接触到什么攻击成功的影响有多大拿一个典型的工业传感器节点来说。资产包括固件本身、固件里的对称密钥和证书、传感器采集的数据、以及与上位机通信的会话。攻击者可能隔着一个网络发起远程攻击也可能直接拿螺丝刀拆开外壳把调试线焊到板子上甚至买一台二手设备回来慢慢逆向。如果产品是部署在无人值守的室外环境那本地物理攻击是几乎必然发生的。很多人习惯把嵌入式安全等同于“芯片有安全启动”“通信有TLS”但威胁建模会告诉你这两条远远不够。比如一个攻击者通过串口日志拿到了堆布局再配合一个栈溢出漏洞就能绕过所有密码学保护直接执行代码。再比如一个设备虽然有安全启动但密钥在工厂烧录时用的是同一个默认值——那就等于所有人都有你家的钥匙。这里我一般会建议团队画一张简单的攻击面清单调试口、OTA通道、网络服务、传感器接口、外部存储、供电侧每一项都标注可被谁接触、成功利用的难度、最坏影响。这张表画完哪些安全特性是真正必要的哪些是锦上添花心里就有数了。1.2 安全特性是用来防坏人不是用来“显得专业”我拆过的不少“安全设备”表面参数好看支持AES-256、有TLS、有安全启动。但实际一测AES密钥是硬编码在固件常量区里的调试口开着串口调试日志打着明文密钥。这样的产品宣传页写什么并不重要攻击者只需要一个常见的读保护绕过工具。伪安全还有一个典型表现只在一个点做加密其他全是明文裸奔。比如OTA固件包做了AES-CBC加密但密钥通过同一个OTA通道下载或者直接把密钥打包在固件里。这种“加密”除了消耗CPU一点用都没有。真正的安全设计是让攻击者每突破一层都会付出代价拿到一份固件不能解密另一台设备的数据拿到写权限不能持久驻留拿到一个设备不能批量复用到整个产品线。我见过一个反例某团队花了大力气给通信链路上了国密算法结果设备管理后台是裸HTTP管理员密码明文传输。攻击者根本不需要破解通信加密直接抓包拿密码登录后台就行。这种把劲使错地方的案例在行业里每天都在发生。1.3 硬件安全特性不等于自动安全现在主流的MCU和MPU都提供了一堆安全特性比如安全启动、eFuse密钥、TrustZone、加密引擎、安全单元。但这些特性只在配置正确的前提下才会生效。拿TrustZone来说如果你把Secure World的代码和数据放在了内存的非安全区域或者地址空间控制器的配置和实际内存映射对不上TrustZone就是个摆设。后面我会专门用一节讲AXI总线上的安全属性能把多少工程师绕晕——这是我自己踩过的地方。另外要提醒一点硬件安全特性本身也分强弱。有些芯片虽然号称有安全启动但它的BootROM允许跳过签名检查或者签名算法弱到可以碰撞。选型时不能只看数据手册上的特性列表要去看芯片厂商的安全勘误表、安全白皮书确认这套机制在实际上电流程里真的不可绕过。2. 安全启动与可信根设备的第一口气2.1 信任锚从片上ROM那一点不可变代码开始安全启动的思路其实很朴素一个计算设备上电后总有一小段代码必须先跑起来。这段代码如果被篡改后面的一切都是空中楼阁。所以芯片厂商的做法是把第一段启动代码固化在芯片内部的只读ROM里它不能改这就是信任根。BootROM再去加载第二段验证第二段的签名第二段再验证第三段……每一级的验证通过信任就沿着链传下去。这里的关键点是每一级只信任上一级而最终的公钥必须锁在硬件里。常见的做法是把固件签名验证公钥的哈希烧进熔丝或一次性可编程区域BootROM在启动时先计算待加载镜像的签名再把算出来的公钥哈希和熔丝里的值比对。这样做的好处是即使镜像被替换因为没有对应的私钥签名验证必然失败。我在实际项目中经常会遇到一个困惑签名算法到底选RSA还是ECDSA。我的经验是同等安全强度下ECDSA的密钥更短、签名验证更快但实现细节更复杂对随机数质量要求高RSA验证逻辑更直观很多老旧工具链支持更成熟。如果芯片有硬件RSA加速器选RSA-2048很稳妥如果纯软件跑ECDSA P-256往往性价比更高。但无论选哪个哈希建议至少SHA-256起步。2.2 防回滚除了防篡改还要防“降级”只做签名验证还不够。攻击者手里可能有旧版本的合法固件——这些固件是历史上发布过的签名没问题但存在已知漏洞。如果芯片允许把固件“降级”回旧版本攻击者就可以先降级再在旧固件基础上发起攻击。这就是为什么安全启动必须配合单调计数器或防回滚机制。实现层面要么在安全存储里维护一个版本号镜像里的版本号必须单调递增要么利用一次性可编程区域的特性把版本号烧进熔丝只增不减。注意这里有一个工程坑一旦版本号烧进一次性区域就不可能退回旧版本。所以量产前的测试必须充分否则一个bug就能让设备永远无法升级到某个版本以下。我见过不止一次研发为了省事在开发阶段就烧了版本锁结果发布后发现固件有严重问题只能全体返厂换芯片。2.3 密钥管理与产线注入安全启动的私钥是整个信任链的命根子。私钥一旦泄露所有设备的安全性都归零。所以私钥必须离线保存最好是放在硬件安全模块里签名操作在硬件安全模块内部完成私钥永不离开设备。为了控制风险还可以做密钥分层主密钥离线保存每次发布固件用主密钥派生或签发一个发布密钥用发布密钥签编译产物这样即使发布密钥泄露也能吊销不用动主密钥。产线注入是另一个大头。设备唯一的密钥和证书如果在出厂时用同一个默认值烧录基本等于没有。量产阶段要有一个可审计的产线工具每台设备生成随机密钥通过安全通道写入安全存储并导出与之配套的证书。这个流程可以配合序列号、型号、签发日期生成设备证书后续运维、OTA、调试都基于这个设备身份。我建议在产线流程里加一个双人复核环节尤其是烧录熔丝这类不可逆操作。曾经有个代工厂误刷了配置把一整批设备的调试口锁死返工成本非常高。密钥注入脚本也要做完整性校验防止产线电脑被污染后往设备里注入攻击者控制的密钥。3. TrustZone与AXI总线上的安全边界3.1 安全位的总线之旅ARM的TrustZone体系通俗地讲是把CPU分成Secure World和Normal World两个状态但真正隔离的战场在总线上。CPU发出的每一次读写事务都会带上一个安全属性标记AXI总线上叫NS位如果是ARMv8-M的MCU则体现在SAU和IDAU的配置结果。这个标记会跟着事务一路走到内存控制器、外设总线、中断控制器。谁允许访问、谁应该拒绝就看这些下游组件认不认这个标记。所以“AXI non-secure enablement”这件事本质上就是在配置总线上的这些检查点哪些地址区间属于安全、哪些外设只能安全访问、哪些中断是安全中断。要是这一层配错了Secure World以为自己在保险箱里实际却把底裤漏给了Normal World。我遇到过一位工程师他以为只要在启动代码里切到Secure状态后面代码就自动安全了。结果Normal World的Linux内核直接映射了安全内存的物理地址一个普通应用就能读到Secure World的密钥。问题就出在总线层面没有配安全属性CPU状态切换只是软件层面的一个标记硬件读写根本不受限。3.2 TZASC/TZMA/TZPC先画内存地图再动手在具体芯片上这些检查点有各种名字。在NXP i.MX系列里叫TZASC和TZPC在ARM CoreLink互连里有TZMA在部分MCU里是SAU加IDAU。不管叫法怎么变逻辑无非两块内存区间的安全属性分配和外设访问的安全策略配置。我的建议永远是动手配寄存器之前先把整张内存映射表画出来。拿常见的双核SoC举例DDR 128MB可以给Secure World划掉顶部16MB用作安全数据区底部给Normal World跑Linux片内SRAM的某段分给安全固件做栈和堆SPI Flash的某个分区放安全世界自己的代码和密钥。然后对着这张表逐项配置地址空间控制器的区域基址、大小、安全属性。每配置完一个区域就在安全世界里写一段测试代码去读写边界两侧确认访问行为符合预期。这一步偷懒后面调试会痛不欲生。外设层面的保护也要同步做。比如一个UART控制器如果业务上只有Secure World能用那就把它配置为安全外设Normal World访问直接返回错误。还有中断控制器安全中断必须路由到Secure World不能让Normal World随意屏蔽或伪造安全中断。配置完还要做一轮Negative Test也就是故意让Normal World去访问不该访问的区域确认硬件真的会拒绝而不是靠软件自律。3.3 边界配错的典型症状从“启动死机”到“静默崩溃”TrustZone边界配错的症状是很有迷惑性的。最普遍的是安全世界的代码初始化到一半就死在某个地址访问上或者Non-Secure侧一碰某个共享外设就挂。还有更隐蔽的表面上两边都能跑但是共享缓冲区被Normal World乱改Secure World收到伪造数据数据校验失败率奇高。排查的时候不要一上来就改寄存器。先看芯片的错误状态寄存器确认是哪一笔事务、哪个地址、什么方向触发了禁止访问然后用最小复现的方式在Secure World侧把目标地址读一遍Normal World侧同样操作一遍对比差异。如果你手上有带调试追踪能力的开发板还可以用调试器看总线事务的属性位。最关键的认知是配TrustZone不是配一次就完。只要改了内存布局、DDR初始化参数、外设地址映射安全配置就要跟着重新过一遍。我见过太多出问题的情况都是“之前能启动”然后就再没人碰过安全配置直到换了一颗DDR颗粒设备忽然在启动早期就死机查了半天才发现是地址空间控制器的区域大小没覆盖新内存。4. 调试口是双刃剑从SecureCRT到JTAG的攻防4.1 串口日志最常被忽略的信息泄露调试口是嵌入式系统里最容易被忽略的安全敞口。很多研发默认串口只是“拿来打印调试信息的”产品发布时日志都不清理但这恰恰是攻击者最喜欢的入口。先说串口终端工具这一环。SecureCRT这类工具几乎是嵌入式开发者的标配好处是协议支持全、脚本化方便。但也正因如此它默认会保存会话、会记录日志甚至会用一些便捷方式保存登录凭据。如果开发者的电脑中招或者日志文件不经处理就被发到外部设备地址、用户名、调试口令、甚至密钥派生过程中的中间值全都会泄露。我的习惯是调试机上对每个项目单独建角色串口会话关闭历史记录日志文件单独加密存储不用默认路径。很多人觉得这些细节啰嗦但攻击者做信息收集时这些文件就是第一桶金。另外串口本身的物理暴露面也要注意。很多设备的调试串口在PCB上直接引出排针没有做任何访问控制。只要攻击者能拆开外壳焊几根线就能看到启动日志和系统输出。如果产品有防拆需求调试串口要么不引出要么在发布前从硬件上去掉测试点。4.2 从日志脱敏到编译裁剪产品固件的调试日志到了发布阶段必须系统性处理。我见过一个血的教训研发在密钥派生函数里加了一条调试打印把派生中间值打到了串口发布时忘记关掉。攻击者从串口日志里直接逆出了主密钥整个产品线的加密体系就此报废。所以发布构建必须与调试构建分离开。最稳妥的做法是在构建系统里加编译开关发布构建默认定义NDEBUG所有敏感打印在预处理阶段剔除同时用静态扫描脚本检查是否还有密钥、证书、内存地址等关键词会出现在日志路径里。还有一点即使不开日志复位原因、栈回溯这类信息也可能暴露内存布局生产固件里该裁剪就裁剪。我还会在代码评审阶段专门看一遍所有日志打印点确认哪些信息是调试期专属哪些是运行期必须保留。遇到实在要保留的运行日志也要做脱敏处理比如只显示设备序列号的后四位不显示完整密钥指纹。日志分级要明确错误、警告、信息、调试、跟踪发布固件最多开到警告级别信息级都建议关掉。4.3 JTAG/SWD锁定与调试认证相比串口日志JTAG和SWD更致命。有了调试口攻击者可以直接读写内存、单步执行、绕过安全启动。所以量产设备几乎无一例外都要锁定调试口也就是把芯片的调试访问权限用熔丝或一次性可编程区域关掉。但完全锁死调试口也有问题售后返修、现场分析都需要调试。因此现在的主流方案是调试认证芯片上电后调试接口是被锁的只有持有正确认证证书的开发工具才能临时打开调试权限。ARM CoreSight的调试访问锁定、各芯片厂商的调试认证基本都走这个路子。前提是你必须管理好这批调试认证证书——它们和主密钥同样重要丢了或被拿走设备还是裸奔。实践上我建议把调试口策略写进发布检查清单发布前确认熔丝已烧、调试日志已关闭、调试口锁定已启用。这些动作做完再去谈什么密码学。另一点是供应链安全如果代工厂需要调试权限来刷机那整个调试认证流程都要跟代工厂签订协议用完即吊销不能让调试私钥长期躺在代工厂的服务器上。5. 嵌入式TLS与SSH证书验证为什么总翻车5.1 设备端TLS的资源账本与常见坑嵌入式设备对外提供安全通信最常用的就是TLS。但跑过TLS的人都知道握手开销对MCU很不友好内存、CPU、证书链、随机数每一项都是大头。于是很多嵌入式方案为了省资源就把验证逻辑砍了TLS变成了一碰就碎的“安全”。更隐蔽的问题是证书验证。设备作为TLS服务端时如果用的是自签名证书客户端工具默认会拒绝连接如果想要客户端信任设备要么把设备证书的CA导入到客户端信任区要么设备使用由用户CA签发的证书。但很多产品的做法是设备端只放了证书没放完整CA链或者证书过期了而设备没有可靠的时钟——设备时间停在2020年证书自然验证不过。在选型时TLS协议栈也要有取舍。mbedTLS是嵌入式领域的事实标准裁剪灵活但默认配置下功能很多如果不做裁剪光代码段就几十KB。如果芯片资源实在太紧可以考虑用PSK模式代替证书模式省掉证书解析和验证的代码。但PSK模式也有自己的问题密钥配送和管理比较麻烦不适合跨组织的大型部署。5.2 “连接应该安全但我看不见证书”的排查链路我最常收到的问题是开发者对着Python客户端报错挠头“if you believe the connection should be secure, but python cannot see the certificate”——这类错误往往是ssl模块在告诉你我无法验证这个连接的身份。原因可能很多但80%集中在下面四个点。第一看时间。设备系统时间和客户端系统时间先校准到同一个参考设备时间不对是证书验证失败第一杀手。第二用openssl s_client -connect IP:端口 -showcerts检查设备实际发出的证书链看是不是只有叶子证书没有中间证书。第三看证书CN和SAN是否匹配访问地址——你别用IP地址访问证书却只签了域名自然不匹配。第四确认客户端加载了正确的CA根证书别把自签名证书当成根证书也别把PEM格式弄成DER还在代码里硬读。这里我单独讲一下Python的坑。Python的ssl模块默认会加载系统的CA证书包但你用自签证书时必须显式构建一个SSLContext然后用context.load_verify_locations加载你的CA文件。很多人直接把设备证书贴到验证位置却忘了设备证书是叶子证书而不是根证书于是验证永远失败。调试时先用openssl把证书链拉到本地肉眼确认一下签发关系比在代码里瞎猜高效得多。5.3 SSH管理通道的加固清单SSH是嵌入式设备最常用的远程管理通道它的坑在于默认配置。很多设备固件直接用了OpenSSH默认配置密码登录开着root账户开着允许的算法列表还包含已经被弃用的算法。这样的SSH通道碰上弱口令攻击等于给攻击者留了条大路。在嵌入式设备上做SSH加固我的清单是禁止root直接登录改用普通用户加权限提升只允许密钥认证禁用密码认证把允许的密钥交换算法、对称加密算法、消息认证码算法收窄到当前推荐的强度限制可登录的客户端IP范围如果适用的话把SSH服务降到非特权用户运行。另外别忘了管理私钥的存储最好放进安全元件或Secure World否则攻击者读个flash管理密钥就全出来了。还有一点SSH的密钥轮换。很多设备的SSH主机密钥是出厂时固定的甚至同一型号全部相同。这意味着攻击者拿下一台设备就能解密同一型号所有设备的SSH会话。正确做法是每台设备在首次启动时生成唯一的主机密钥并且支持后台轮换。这个细节很多团队会忽略但攻击者眼里这就是一马平川的突破口。6. 嵌入式Web管理界面的“安全源”幻觉6.1 “insecure origins treated as secure”是怎么来的带Web管理界面的嵌入式设备越来越多从路由器到工业网关甚至充电桩。开发的时候大家往往图省事直接用HTTP。等浏览器开始疯狂提示“不安全”有人就开始搜解决办法然后搜到一条Chrome启动参数--unsafely-treat-insecure-origin-as-secure...。只要加上这个参数测试时浏览器就不再抱怨了。但这只是本机调试的权宜之计把它写进测试脚本、甚至发布文档就是自我欺骗。生产固件里不能让用户天天加启动参数去访问“安全”管理界面。真实的工程问题不是让浏览器闭嘴而是让设备的Web服务真正跑在TLS上同时处理好证书信任和设备发现这两件事。“insecure origins treated as secure”这个选项它存在只是为了限时调试不是给你的产品兜底。我还见过一种更危险的做法把HTTP和HTTPS同时开着HTTP端口只做重定向到HTTPS。这个思路本身没毛病但如果HTTP端口的重定向逻辑有漏洞或者某个接口漏配了反向代理用户实际访问的还是明文页面。部署完之后用浏览器和curl分别对80和443做一轮完整扫描确认没有非预期接口暴露。6.2 嵌入式Web服务器如何做HTTPS化改造嵌入式Web服务器的HTTPS化说白了还是证书问题。设备出厂时不可能预知用户会用哪个域名或IP访问它所以最实际的做法是设备首次开机时在本地生成ECDSA或RSA自签证书证书的SAN包含设备的序列号、mDNS域名和本机IP管理端第一次连接时向用户展示证书指纹用户在浏览器里点击信任。这个方案虽然自签名但配合首次信任模型比裸HTTP强太多。代码层面的坑也不少。很多嵌入式Web服务器基于轻量级框架或自研socket要支持TLS就得接上mbedTLS或OpenSSL。我提醒几个细节不要用SSLv3或TLS1.0最低TLS1.2证书私钥不要放在可写分区要放在只读分区或安全存储里会话票据的密钥要随机生成并定期轮换尽量只保留HTTPS别留个80端口当后门。证书生成的方式也要谨慎。设备端的私钥如果在文件系统里用明文存储那把flash读出来就全暴露了。比较好的做法是把私钥生成放到安全世界或安全元件内部让私钥永不离开安全边界。就算Web服务器进程被攻破攻击者也拿不到可用于伪造身份的私钥。6.3 适配浏览器策略变化从Chrome到Safari浏览器的安全策略一直在变嵌入式Web管理界面是最容易中招的领域。Chrome把HTTP标记为不安全、对混合内容更严格、HSTS预加载列表越来越大——你可能在小众浏览器里自测没问题但客户用最新版Chrome一打开页面里的图片和脚本被当成混合内容拦掉了。要避免这种局面我建议把兼容测试列为发布流程的一环用最新版Chrome、Firefox、Edge、Safari分别访问设备的Web界面检查页面是否全站HTTPS、是否存在HTTP子资源引用、证书链是否完整。另一个容易被忽略的点是时间设备时间错误时浏览器会因为证书有效期问题直接拒绝管理界面所以支持HTTPS的嵌入式设备一定要有可靠的时间同步机制比如通过NTP从内网同步。时间不准的设备证书从第一天起就是过期的。还有HSTS的问题。HSTS头一旦下发浏览器在有效期之内会强制跳转HTTPS。如果设备是临时用IP访问的HSTS可能不影响但如果设备绑定了域名那改回HTTP调试就会非常痛苦。我的建议是嵌入式设备默认不开启HSTS除非你确定用户永远只用HTTPS访问并且有证书信任保障。否则一旦证书问题导致用户无法访问连降级HTTP调试的路都没了。7. 资源受限下的安全机制取舍7.1 安全系统的资源账单内存、CPU与启动时间在嵌入式领域安全特性不是免费的。跑一个TLS握手证书链表和握手缓冲区可能要吃掉几十KB栈和堆Secure World的固件、安全配置的页表、加密引擎的上下文切换都会增加RAM占用。项目群里时不时有人问“安全系统占内存怎么降下来”这其实不是某个进程的锅而是整个安全机制堆叠后的结果。我的建议是先把账单列出来安全启动增加多少启动时间TLS握手峰值内存是多少加解密吞吐能不能满足业务Secure World的栈和堆各占多少做成一张表逐项优化。优化完再做一次全量回归确认这些改动没有突破当初的威胁模型边界。有一个容易被忽略的点是DMA缓冲。很多硬件加密引擎需要DMA缓冲区如果缓冲区没有按安全属性正确配置就可能出现安全世界的敏感数据被DMA写到非安全内存的问题。这个问题在资源紧张、缓冲区复用频繁的场景下特别常见。做资源优化时缓冲区归属和安全属性必须同步检查。7.2 硬件加速器与裁剪思路按需取舍优化可以从两个方向入手。一是裁剪软件栈TLS协议栈在编译时有很多配置宏按需开即可比如不需要证书校验就把证书解析的代码裁掉握手时使用会话复用或会话票据避免每次连接都做完整握手能走PSK模式的就不走证书模式PSK模式下内存和CPU开销能降一大截。二是启用硬件加速。现代MCU普遍带AES、SHA、RSA、ECC硬件引擎把这些引擎接进TLS协议栈的加速层之后加解密吞吐可以翻一个量级CPU占用大幅下降。但要注意硬件引擎的驱动和DMA缓冲本身也要吃内存配置不当可能让吞吐不升反降。实测下来把硬件加速之外还要把缓冲区管理理顺才算真正省了内存。如果是追求极致资源的场景还可以考虑用纯对称算法的自定义安全协议替代TLS。但这里我要泼一盆冷水自研安全协议几乎都是错的。如果你不熟悉密码学协议设计别自己去发明握手、抗重放、密钥协商。用现成的TLS-PSK、DTLS-PSK裁剪到最小配置安全性和资源占用都比你自研靠谱得多。7.3 分层的取舍并不是所有数据都值得用最重的保护在资源受限的芯片上安全方案必须分层。我的原则是第一优先级保护密钥和信任根第二优先级保护代码完整性第三优先级保护敏感数据。比如一个低成本的BLE传感器它没有跑TLS证书的能力那通信就可以走PSK加密真正的密钥管理放在Secure World和一次性可编程区域里固件有签名验证和防回滚。这样用有限的内存把最核心的风险堵住。做取舍时要把风险决策记录下来。今天为了省RAM砍掉的功能明天在威胁模型里算不算可接受风险这是设计评审时要说清楚的。我见过有人为了省内存把设备证书直接砍了结果后期客户强制要求合法证书只能大改。安全设计不是一次配置是要跟着威胁和需求变化持续调优的。还有一点安全功能的开关要做成运行时和编译时可配置而不是改代码再发布一版固件。有些部署场景对内存要求极高有些场景对合规要求极高一套固件走天下往往会顾此失彼。把安全等级做成配置文件让现场人员按部署环境选择能大幅减少“为了极端场景牺牲所有场景”的问题。最后说点个人体会。嵌入式系统安全开发跟写业务代码不一样它的核心是在每个设计决策里追问一句“这个决定如果被攻击者利用会怎样”。我踩过最大的坑就是把安全当成了一堆特性的叠加有了安全启动就以为万事大吉结果调试口开着配了TrustZone却忘了同步更新地址空间控制器跑通TLS就不再检查证书链。安全不是某个芯片、某个算法、某个工具带来的它是从第一行启动代码到最后一层管理界面的持续维护。希望这些经验能帮你少走点弯路。