如果你做过嵌入式安全测试一定遇到过类似的困境功能测试做得顺风顺水安全测试却像泥潭一样拖人。被测设备可能是一块车载域控制器、一台医疗泵或者一个智能门锁攻击者不会按你的功能用例出牌他们盯的是侧信道泄漏、电源毛刺下的异常行为、未加密高速链路上的敏感数据流。我自己在给某工业控制板做安全评估时光是在功耗曲线上定位AES密钥轮次的位置就折腾了近一周。最近Keysight推出下一代嵌入式安全测试台Embedded Security Testbench正好把这类测试从“拼设备、看波形、靠手感”的野路子拉到了可标准化、可复现、可自动化的轨道上。从测试测量厂家的角度看这套测试台的本质是把“攻击”变成一组可控的激励和测量。它解决的并不是某个单一漏洞而是嵌入式系统安全验证的完整链路供电不稳定时设备会不会出错、功耗曲线里会不会泄漏密钥、高速接口上有没有被篡改的风险、协议层能否承受异常数据冲击。适合读这篇文章的主要是硬件安全工程师、芯片原厂验证团队、第三方安全检测实验室以及想在公司内部搭安全测试能力但不知道从哪下手的研发负责人。下面我按自己动手搭平台的经验把下一代测试台拆开讲清楚。1. 项目定位这台嵌入式安全测试台到底解决了什么1.1 为什么功能测试替代不了安全测试很多团队会问普通的功能测试、信号完整性测试难道不能兼顾安全验证吗答案是不行而且差别很大。功能测试的前提假设是“设备必须按照规格书工作”测试项围绕时序、协议、电气参数展开比如I2C时序是否满足、DDR读写是否稳定、MIPI信号眼图是否符合规范。安全测试的前提假设则反过来了是“设备会遭遇规格书之外的输入”攻击者会故意拉低电压、注入毛刺、在总线上插入错误数据观察设备有没有泄露敏感信息或者跳出安全状态。这种场景差异决定了仪器配置完全不同。功能测试里的示波器主要看眼图和抖动触发条件追求稳定安全测试里的示波器要能够精确捕获瞬态功耗曲线并且和加密运算状态对齐。你甚至需要一台能够编程控制的上位机testbench把电压扰动、时钟毛刺、协议异常按序列注入被测设备同时记录响应。传统仪器选型思路在这里并不适用这正是Keysight推出独立嵌入式安全测试台的根本原因。我见过不少团队用一台普通直流电源加示波器去测安全场景结果电源响应太慢毛刺根本没有打进去测了半天设备全正常给了管理层一个“我们很安全”的错误信号。这不是他们不努力而是缺少一个专门为“恶意激励”设计的环境。1.2 下一代测试台的目标场景和用户群从公开信息来看这台嵌入式安全测试台的重点场景主要有三类一是带安全加密功能的物联网设备和智能终端需要验证AES、RSA、ECC算法实现是否存在侧信道泄漏二是汽车电子中的ECU、域控制器、T-Box这类产品不仅要过功能法规还要满足ISO/SAE 21434里关于安全验证的要求三是工业控制器、医疗电子和关键基础设施设备安全测试的结果往往直接和认证挂钩。它的用户画像也比较清晰。第一类是芯片原厂的安全验证工程师他们需要在对流片回来的样品做安全评估时快速确认密码模块在功耗、电磁辐射层面的表现。第二类是安全实验室的测试人员他们要按标准的方法复现攻击并出具可追溯的测试报告这就需要测试台本身有标准化的流程和记录能力。第三类是产品研发团队他们不一定要做深入攻击但希望在开发阶段就发现明显漏洞比如固件能直接被调试接口读取、密钥明文存放在Flash里、MIPI视频流完全未加密。我自己的经验是一个完整的嵌入式安全测试台并不等于买台高大上的仪器放实验室里而是要形成“激励-测量-分析-报告”的闭环。Keysight这套方案明显是按闭环思路设计的而不是简单地把几个仪器打包售卖。1.3 和传统方案相比下一代最核心的变化是什么传统嵌入式安全测试方案通常是零散的故障注入用小工具自己搭FGPA侧信道采集用示波器加脚本协议fuzz又换另一套开源工具。测试用例之间没有统一调度数据格式也不互通最后做报告时要手动导好几遍数据。最痛苦的是一次测试环境和下一次测试环境之间差异很大换个团队就复现不了后面审计的时候很难解释。Keysight这套下一代测试台把“攻击用例”和“测量通道”统一在同一套testbench框架里。官方资料里强调的几个维度我理解下来是第一故障注入和功耗采集不再分离而是共享同一个时间基准这样能够明确知道每一次干扰发生在密码运算的哪个阶段第二仪器自动化程度更高通过标准SCPI命令和Python脚本就能驱动整套环境不需要自己费劲去协调各台设备第三引入了设计阶段预仿真工具链也就是ADS软件的协同可以把安全测试提前到PCB设计阶段而不是等硬件做出来再返工。简单比喻一下传统做法相当于你请了电工、钳工、焊工分别来干活互相之间没有统一进度表下一代测试台相当于一个施工总包工具、工序、验收标准都是串好的。2. 核心模块拆解从激励到分析的五层结构2.1 电源与信号激励层故障注入是核心能力看过安全测试的读者应该知道嵌入式设备最容易被打穿的方向之一是对电源域或时钟域注入毛刺让芯片内部的程序执行顺序发生错乱绕过密码校验或者安全等级判断。Keysight测试台在这一层用的是高带宽可编程电源和信号发生器。可编程电源负责电压跌落故障要求上升和下降沿足够陡且电压建立时间能精确到几十微秒以内才能真正干扰到核心逻辑信号发生器则用于叠加更高频的干扰信号覆盖谐振点的攻击场景。做故障注入最关键的是参数控制。拿电压毛刺举例核心电压1.0V的设备典型攻击参数是毛刺幅度从700mV到1.2V脉宽从50ns到1ms注入时刻相对加密触发器延时从100ns到10ms扫描。你可以用二分搜索快速定位最容易导致设备出错的时间窗口。如果没有可编程的自动扫描能力靠手工旋转旋钮调制参一晚上也扫不了多少点。这也是为什么安全测试台一定需要软件自动化的原因。在具体操作时需要通过示波器通道同时监测核心电压和密文输出引脚。测试台的时间对齐功能在这里非常有价值它能把毛刺注入点、功耗曲线、芯片输出状态对齐到同一条时间轴上否则你根本无法判断毛刺是落在密钥加载阶段还是密文输出阶段。2.2 测量与采集层高速示波器不只是看波形安全测试对示波器的要求有时比普通高速信号测试更苛刻。普通信号测试看的是波形是否满足阈值和时序安全测试中反而更关心波形的细微变化尤其是功耗曲线上的小幅度跌落或电磁辐射的窄脉冲。这要求示波器有足够高的垂直分辨率而不只是高带宽。Keysight主流的Infiniium系列示波器在高分辨率模式下的有效位数可以做到10bit甚至更高这对区分AES最后一轮功耗和前面几轮功耗非常重要。我见过有人用2GHz带宽、8bit示波器做功耗采集结果功耗曲线噪声基底太高密钥特征完全被淹没。后来改用高分辨率模式并适当降带宽滤波才勉强看到轮次边界。这里的经验是侧信道采集不像测高速数字波形优先级应该是“垂直分辨率 带宽 采样率”。采样率保证每个时钟周期内能采到足够多点数一般为被测时钟频率的5到10倍比如目标时钟32MHz采样率250MSa/s以上基本够不需要一味堆到10GSa/s。在安全测试台里示波器还承担着触发角色的任务。你可以把被测设备发送的某个特定串口输出或LED翻转信号作为触发启动功耗曲线采集。这样每次采集到的曲线都能从同一个运算起点对齐后面做差分功耗分析DPA时数据才能用。2.3 高速总线协议分析MIPI接口的安全验证最近不少读者问到“Keysight示波器如何测试解析MIPI高速信号”放在安全测试的语境下这个问题变得更有意思。MIPI接口广泛用于手机摄像头、显示器和汽车座舱域里面跑的是视频流和控制命令。如果视频流没有加密攻击者完全可能通过物理靠近、电磁探测或者向接口注入特定格式的数据来干扰识别系统或者窃取画面隐私。用Keysight示波器解析MIPI信号需要做到三个层面物理层看眼图和电平协议层看包结构和负载内容系统层看总线空闲期和异常报文。以MIPI D-PHY为例数据速率可以到2.5Gbps纯物理层测量建议用至少4GHz带宽示波器若要看第3次谐波或做一致性测试则建议8GHz以上。实际操作时需要用差分探头探测MIPI数据线和时钟线然后在示波器上选择对应的MIPI解码选项设置LVDS差分电平阈值再在解码表中定位包头的SoT和包尾的EoT。关于安全验证我建议在MIPI眼图和协议解码之外多做一个总线异常注入测试。利用信号发生器向MIPI数据线上叠加毛刺观察接收端是否出现CRC错误或者错误包被丢进应用层。这个测试在传统信号完整性实验室里很少做但对安全评估非常关键。测试台如果把这部分也纳入自动化就能在MIPI链路上达到“异常输入可追踪、响应可记录”的效果。2.4 软件层策略ADS预仿真与自动化testbenchKeysight ADS软件在射频和高速数字仿真领域用得很多但和安全测试结合得相对低调。实际上设计阶段用ADS做安全预仿真能够提前发现很多硬件层面的风险点。最常见的是电源完整性攻击模拟你可以在ADS里建立PCB供电网络的模型加入一个干扰源看它在不同频率下对敏感器件电源引脚的噪声耦合量级。我从实际项目的角度看ADS的价值不在于替代真实测试而在于帮你在画板子之前筛选方案。比如一个安全MCU的供电去耦电容摆放在板子的哪一侧更不容易被外部电磁干扰注入用ADS仿真几分钟就能出一个趋势结论比等PCB回来后反复焊探针试要高效得多。当然仿真模型精度取决于搭建的寄生参数是否准确但这不影响它在早期设计阶段的指导价值。自动化testbench软件层则负责把整个测试流程串起来。简单来说脚本需要控制信号源发射毛刺、控制示波器采集波形、控制被测设备进入特定状态再把数据汇总成报告。Keysight提供的仪器驱动库支持Python和SCPI命令我可以直接在电脑上写脚本按序列自动切换攻击参数最终生成测试矩阵。这种模式比手动操作可靠得多尤其是需要跑几千组参数扫描的时候。3. 手把手搭建一套可复现的嵌入式安全testbench3.1 硬件连接与仪器配置搭建一套基础版安全测试台核心仪器不需要太多一台高分辨率示波器、一台可编程信号源或电源、一台可控负载或者精密电流探头再加一台用来控制被测设备的上位机。以我常用的配置为例被测设备是一块带安全芯片的开发板内部跑AES-128加密。硬件连接是可编程电源给开发板供电通过精密电流探头连接示波器的模拟前通道信号源的输出接到开发板的复位引脚或时钟引脚用于注入干扰开发板的UART输出接到示波器的数字通道作为触发信号。第一次上电前我会先用固定电源白名单方式验证基础功能确保开发板能正常启动和通信。然后逐步把信号源输出调到“干扰前不影响正常功能”的基线状态再开启自动化扫描逐步增加毛刺幅度。这里的配置建议是示波器采用高分辨率模式带宽设为200MHz到500MHz限制采样率设为250MSa/s到1GSa/s触发源选UART串口输出或者GPIO状态翻转。要注意探头选择。电流探头会带来带宽限制一般能到几十MHz到几百MHz对于功耗变化跟踪足够如果测更高频的局部功耗建议用同轴SMA直接取样电阻把串联取样电阻上的电压送到示波器。不同方式的噪声特性差异很大建议在测试台上预先标定好各通道的噪声底写入配置文档。3.2 用Python加SCPI指令实现自动化测流程testbench最核心的优点是可重复性。手工操作最大的问题是参数设置可能有微小差异导致测试结果之间不可比。通过SCPI指令控制仪器后整个序列可以一键跑完并且每次运行参数都严格一致。我一般用Python写自动化脚本按以下几个步骤执行。第一步初始化所有设备地址检查是否在线。第二步配置示波器关闭通道、设置垂直衰减、时基、触发模式和采样率。第三步配置信号源设定毛刺幅度、脉宽、触发延时和重复次数。第四步执行一次预扫确认波形触发正常。第五步进入参数扫描循环例如幅度从0.6V到1.2V、步进20mV延时从100ns到10ms、按反对数间隔取100个点每组参数注入50次并记录输出数据。一个简化示例代码如下import pyvisa rm pyvisa.ResourceManager() osc rm.open_resource(USB0::0x2A8D::INFINIIUM::MYXXXX::INSTR) sig rm.open_resource(TCPIP0::192.168.1.100::INSTR) osc.write(:CHAN1:DISP ON) osc.write(:ACQ:SRAT 500000000) osc.write(:TRIG:EDGE:SOURCE CHAN3) for duty in [0.1, 0.2, 0.3]: sig.write(f:PULS:WIDT {duty*1e-6}) sig.write(:OUTP ON) osc.write(:SINGLE) # wait for acquisition complete # save waveform data osc.write(:WAV:DATA?)这段代码里最关键的是等待示波器采集完成以及分析时正确对齐每次采集到的波形。如果触发条件设置不严可能出现一次采到加密全流程另一次只采到其中一段最后的曲线对不齐DPA分析自然无效。3.3 用ADS建立设计阶段安全预仿真模型很多嵌入式硬件团队对ADS的印象停留在射频设计但实际上它处理低速安全场景同样顺手。我最近做的一个项目里需要在关键安全芯片的电源输入前端评估一组LC滤波电路对脉冲干扰的抑制能力。按传统流程需要做两块测试板来对比成本高且周期长。用ADS做瞬态仿真则快得多。在ADS里搭模型时我把电源芯片输出端简化成一个电压源加上一定输出阻抗PCB走线用微带线或者S参数模型代替再从芯片端的SMA连接器加入一个阶跃或者脉冲干扰源。运行瞬态仿真后可以清晰看到干扰脉冲经过滤波电路后在芯片电源引脚上残余的过冲和下冲幅度。如果这个幅度落进了芯片正常工作的噪声容限之内就说明该滤波方案有效。这里要特别强调的是ADS仿真的结果要和真实仪器测量去对标。我会先用标准测试板采集一组实际波形再回填仿真模型参数直到模拟波形和实测波形误差小于10%。这样建立的模型后续做方案对比才有参考价值。很多团队直接把官方模型拿来跑发现不准其实是因为PCB寄生参数没有校准这不是软件的问题是建模流程的问题。3.4 实际项目在车载ECU上做功耗侧信道提取为了说明整个测试台怎么运转我讲一个具体案例。被测对象是一台某方案的车载ECU里面用了一颗带安全启动功能的主控固件校验采用AES-CMAC。我们的测试目标是验证能否通过功耗侧信道恢复出AES轮密钥从而绕过固件完整性校验。测试开始前先让ECU进入一个固定循环的固件校验流程由上位机通过CAN总线连续发送请求。示波器用电流探头采集核心供电的电流波形并把CAN报文的发送信号作为触发。每次波形只截取加密运算的片段存入本地文件。这里要用到Keysight测试台的时间对齐功能确保触发点离密钥加载阶段足够近。我们总共采集了20万条曲线每条包含1024个采样点。随后用常规的DPA分析脚本对波形分组成处理。由于数据量并不算大直接用Python加NumPy就能算。如果功耗曲线噪声较小在两万条曲线左右就能看到明显的相关系数尖峰。我们这次到四万条时已经能定位到密钥的单个字节。整个过程从搭环境到拿到完整密钥两天不到。如果用老办法手动调探头、导出波形、再写脚本分析没一个星期下不来。这个案例充分说明安全测试台的核心价值在于让复杂攻击流程标准化。仪器性能当然重要但让数据采集和分析流程跑得稳妥、可重复才是工程落地的关键。4. 常见问题与排查技巧4.1 示波器触发不到想要的功耗波形的怎么办这个问题几乎每个刚开始做安全测试的人都会遇到。不是示波器不稳定而是触发条件选择不对。功耗波形本身是周期性的但加密运算并不是每次都完全一样尤其有随机数参与时起始位置会变化。正确的做法是选择一个和加密运算强相关的信号做触发比如通信接口的CS片选、IRQ中断或者一个专门给测试用的GPIO翻转。如果板子上没有预留测试引脚我会临时飞线到某个空闲GPIO并修改固件让它和加密函数同步翻转。在量产设备上不能改固件那就用UART波特率信号或者无线收发模块的发射指示引脚。触发边沿建议选择上升沿或下降沿中的固定一边并设置适当的触发电平避免在噪声边沿误触发。还有个排查技巧先跑一遍已知固定数据加密连续触发100次把所有波形叠加看看重叠度是否足够高。如果波形起点抖动大应调整触发模式为holdoff或者改为外部触发。4.2 功耗噪声大应该先滤波还是提高采样率功耗曲线噪声来源很杂包括电源自身纹波、探头噪声、环境电磁干扰和数字电路开关噪声。很多人第一反应是把示波器带宽开到最大结果噪声更大。实际处理应该分两步先降带宽把高于目标频率的噪声滤掉再调整探头和接线方式尽量缩短地线回路。我在采集32MHz目标时钟时示波器带宽设置在200MHz左右已经足够捕捉功耗的主要变化。过高的带宽会引入大量高频数字开关噪声反而淹没密码运算的低频包络。如果做完降带宽噪声还大检查电流探头是否夹在背板供电线上这里容易受到DC-DC开关噪声干扰。更好的方法是把采样电阻直接焊在目标芯片电源引脚前端用短线连到示波器地线要短粗。还有一个容易忽略的点就是示波器垂直档位要匹配被测信号范围。如果功耗信号只有50mV但档位在2V/divADC分辨率严重浪费。将垂直档位调整到信号幅度的2到3倍再开启高分辨率平均模式噪声会改善很多。4.3 MIPI信号测试和协议解码的坑用示波器测MIPI最常遇到的是误触发和协议解码错位。MIPI差分信号共模电压比较低而且工作频率高普通无源探头直接点测会加载信号导致眼图塌陷。处理办法是使用低电容差分探头并校准探头延时至ps级别。电容和地线长度对高速信号的影响非常大建议使用原厂提供的焊点式探头前端而不是用长夹子线。解码设置方面我经常会遇到“有波形但解不出包”的情况。根源往往是数据线极性设置反了。MIPI D-PHY的Dp/Dn如果接反示波器是看不出差分的实际极性的解码自然全错。另外要确认状态机设置正确连续传输模式和非连续传输模式下的Escape序列定义不同容易导致包头识别失败。安全测试场景里我通常不只解正常包还会故意去看那些CRC校验失败的包。示波器解码模块会把错误帧标红这正是我要关注的错误帧出现的频率和注入的干扰参数是否有相关性。如果错误帧随机出现说明是环境噪声问题如果错误帧只在特定毛刺幅度后出现说明攻击窗口已经找到这对后续安全加固很有参考价值。4.4 仪器选型与参数配置参考下面给出我常用的参数配置参考表不一定适合所有场景但可以作为一个起点。带宽和采样率的搭配遵循“够用并且留余量”的原则垂直分辨率要尽量高。故障注入的电源要求快速上升下降沿至少做到微秒级否则低电压毛刺会被电源环路自动修正根本看不到效果。测试方向示波器带宽采样率探头/连接方式其他建议功耗侧信道200MHz-1GHz250MSa/s-1GSa/s电流探头或串联取样电阻高分辨率模式带宽限制MIPI物理层≥4GHz≥8GSa/s差分探头焊点式前端校准探头延时做眼图模板测试故障注入响应500MHz-2GHz2GSa/s以上差分探头或无源探头与注入源共享时基电磁辐射探测1GHz-6GHz实时模式看时域近场探头前置放大器频域分析用频谱仪模式选型上不必追求单台设备覆盖所有场景毕竟安全测试工作台往往需要同时接示波器、信号源、电源、控制电脑通道间同步比单台极限性能更重要。如果预算有限优先投资高分辨率示波器和精密可编程电源这两件是侧信道分析和故障注入的核心。5. 落地经验与扩展建议5.1 安全测试不是一次性任务项目上线前做一次安全测试然后一年不管这种模式在今天的威胁环境下已经不够了。嵌入式设备的固件会更新、协议栈会升级、新攻击方法层出不穷安全验证应该走持续测试路线。Keysight这套测试台从设计上就支持自动化回归所以完全可以嵌进CI/CD里做成定期安全回归跑批。比如每次固件构建完成后自动跑一组基础侧信道泄漏测试、故障注入测试和MIPI异常帧测试发现问题直接发告警给安全团队。这种模式有几个收益第一问题发现得越早越便宜固件还在开发阶段就被抓到功耗泄漏比产品量产后被告知要省大量的召回成本。第二测试结果是可对比的你能看到同一模块从版本1.0到版本1.7在侧信道指标上的变化趋势而不是每次从零开始。我建议刚开始不要追求覆盖全部攻击面而是先选择两个最高风险的用例跑起来形成习惯再逐步增加测试矩阵。5.2 如何把测试结果转化成可用的安全报告实验室里采了几万条波形、跑出相关系数尖峰这并不等于能交付安全报告。给管理层或者客户看需要把技术结果转化为风险描述和整改建议。我在做报告时固定会包括以下内容测试环境描述、仪器固件版本和校准日期、注入参数扫描范围、采集数据量、分析算法、阈值判定依据、风险定级以及复现测试所需的最小操作步骤。这些元素越完整报告被外部质疑时越有底气。这里有一个容易被忽略的点负面结果同样要记录。如果某个注入参数扫描范围内没有发现异常也一定要把扫描范围和步进写清楚。否则你拿着“没有发现问题”的结论出去别人无法判断你是真的测过还是压根没测。记录“为什么这个范围合理”甚至比记录数据更重要它体现了测试的严谨性。另外报告里尽量用图表说明功耗曲线对齐情况和DPA相关系数分布而非只贴原始波形。因为原始波形看起来都差不多真正的价值体现在经过统计处理后的特征上。把这些内容整理成标准模板后后续每次测试只需要替换数据输出效率能提高不少。5.3 从测试台到持续安全测试流水线一个可以扩展的方向把测试台变成流水线是我目前认为最能提升嵌入式安全能力的方向。简单来说就是把前面说的Python测试脚本、ADS预仿真模型、MIPI解码结果和功耗分析全部封装成可调用的测试模块再放进一个统一的任务调度平台。调度平台自动连接仪器、执行测试、收集数据、生成报告并把趋势结果推送给相关工程师。这套流水线对小型团队尤其有价值。原本安全测试依赖个别专家的手工能力专家请假或者离职就断档。而一旦测试模块和流程被沉淀下来新人通过脚本就能复现相同测试团队的安全能力不会绑在单个人员身上。当然把测试模块封装好并不容易需要投入时间和仪器资源但相比每次从零搭环境长期回报是显著的。我个人觉得接下来几年嵌入式安全测试一定会从“安全研究员的专属工具”走向“研发团队的标准测试环节”。届时具备自动化能力、可重复执行、能直接输出报告的安全测试台会成为硬件产品开发流程里的标配。而 Keysight这套下一代嵌入式安全测试台至少在“把攻击方法工程化”的思路上走在了比较前面。最后再分享一个小技巧在做侧信道采集之前用固定密钥和固定明文先做一次完整采集检查波形在密码运算边界处的对齐误差。如果两次同样的测试得到的曲线边界偏移超过一个采样周期先不要继续跑大批量采集回头检查触发设置和时钟稳定性。采集环境干净、数据对齐可靠比盲目堆波形数量重要得多。测试台不是买回来就能自动产生价值真正有价值的是能把它长期稳定用起来的流程和习惯。