第一次接触ECC硬件功耗分析的时候我差点以为用示波器夹两根线就能把私钥读出来。结果连续一周都在跟噪声、触发信号和波形对齐搏斗。后来才想明白标题里的Power Analysis、ECC、Hardware Implementations三个词每一个都足够撑起一门课。这篇文章打算从一个踩过坑的角度聊聊怎么真正动手做一套ECC硬件实现的功耗分析实验包括平台怎么搭、曲线怎么采、相关性怎么算、遇到问题怎么排以及防护方案到底有没有用。内容会尽量贴近实操适合正在做硬件安全、侧信道攻击或密码芯片验证的工程师也适合想入门的同学照着把流程跑通。1. 项目背景为什么ECC硬件功耗分析值得专门写一篇1.1 椭圆曲线密码在硬件里的江湖地位椭圆曲线密码在这几年基本成了安全芯片和物联网终端的标配。原因不复杂同等安全强度下ECC的密钥长度远小于RSA。160位的椭圆曲线密钥大致能对标1024位的RSA256位曲线可以对标3072位RSA。对于智能卡、车规芯片、TEE模块这些面积和功耗都敏感的场景少存几个字节、少算几次模幂就是实打实的成本优势。硬件实现ECC时核心运算落在标量乘法上也就是计算kP其中k是私钥标量P是椭圆曲线上的基点。这个运算看起来只有一行公式落到RTL电路里却涉及大量有限域模加、模乘、模逆以及点加、倍点操作。硬件实现的执行速度快但功耗特征也比软件更规整、更容易被采集。如果设计者只在算法层面做了正确性设计没做侧信道防护那么功耗轨迹里往往藏着密钥的全部信息。我最初接触这个课题时目标很简单在一块FPGA上跑一个未加防护的P-256标量乘法尝试用功耗分析把标量k恢复出来。项目名称叫Power Analysis of ECC Hardware Implementations说白了就是把“功耗分析”和“ECC硬件实现”这两件事绑在一起验证侧信道风险到底有多真实。1.2 先把概念对齐这个ECC不是内存校验码“ECC”这个名字很容易引起误会。搜索时经常蹦出“ecc校验”或者“SAP ECC basis”这两个东西跟椭圆曲线密码完全不是一个世界。ecc校验是内存纠错码解决的是存储位翻转问题SAP ECC basis是企业管理软件里的平台组件跟密码学没有任何关系。我在这篇里提到的ECC单指Elliptic Curve Cryptography椭圆曲线密码。把名字分清楚不是小事。我们当时做项目调研有位同事拿着内存纠错码的资料研究了半天还以为系统里已经内置了抗攻击机制。其实密码学里的ECC和内存纠错只是共享了同一个缩写的缩略词。实际做硬件功耗分析时我关注的是椭圆曲线群运算在设备运行过程中产生的功耗旁路信息而不是内存错误检查和纠正的状态机。命名虽然容易混淆但原理和防护思路差异巨大。内存ecc校验关心数据完整性密码学ECC关心机密性。功耗分析攻击针对的是后者目标是利用物理泄漏还原私钥。所以后面所有内容都围绕椭圆曲线密码展开不再做歧义讨论。1.3 功耗分析解决的是什么问题密码算法设计时大家默认攻击者只能看到输入输出。但真实物理芯片不同芯片工作时要耗电微电子开关活动会在电源引脚上造成微小的电流波动。加密过程不同时刻的中间值不同开关翻转数量也就不同于是功耗轨迹和中间值之间产生了相关性。功耗分析就是利用这种相关性来推断密钥的方法。和故障注入、电磁侧信道、缓存侧信道相比功耗分析的优点是门槛相对低一块示波器加一根采样电阻就能采集到信号缺点是噪声大、波形多、对齐麻烦而且一旦遇到合格的防护措施基本分析会立刻失效。我做这个项目的核心目标就是搞清楚“ECC硬件实现到底泄漏了多少”。实测结果比想象中更直接对于一款没有加任何防护的ECC FPGA实现采集几千条功耗轨迹之后通过CPA相关性能量分析恢复标量k的前几十位密钥成功率接近百分之百。这让我意识到硬件上的密码实现如果不做侧信道设计私钥几乎是裸奔的。2. 功耗分析到底在分析什么2.1 泄漏源头CMOS功耗与数据翻转的关系现代数字芯片绝大多数基于CMOS工艺。CMOS电路的主要功耗来源是动态功耗也就是逻辑节点发生0到1或1到0翻转时对负载电容充放电产生的功耗。一次翻转消耗的能量大致可以写成E 0.5 × C × V²。在这个公式里C和V对特定芯片来说是固定常数可变的是翻转次数。如果某条数据总线从0x00变成0xFF8个比特同时翻转比从0x00变成0x01多消耗不少能量。这种“翻转越多功耗越高”的现象就是功耗模型的基础。侧信道分析里最经典的汉明重量模型认为功耗和中间值二进制表示中1的个数成正比更精细一点的汉明距离模型则考虑相邻时钟周期内寄存器新旧数值之间逐比特翻转的数量。ECC硬件实现中大量数据在寄存器、ALU和存储器之间搬移。每次模乘、点加、倍点都会产生大量确定的中间值。攻击者只要知道或猜出一部分中间值就能用功耗模型去匹配实测功耗曲线。如果某一位密钥猜对了预测功耗和实测功耗的相关性会明显高于猜错的情况。这也解释了为什么“数据相关功耗”是侧信道攻击的核心前提。2.2 ECC硬件实现里最容易被盯上的运算标量乘法ECC的加密、签名、密钥交换底层都是标量乘法。签名算法ECDSA中的私钥k会直接参与计算kGECDH密钥交换中私钥也以标量乘法的方式作用在对方公钥上。可以说保护了标量乘法就保护了ECC的大部分安全性。标量乘法不是一步算完的它由若干轮点加和倍点组成。比如最简单的从左到右二进制扫描算法从最高位开始每轮先对结果做倍点如果当前密钥位是1再执行一次点加。这个流程有一个致命特征密钥位为1时多做一次点加为0时少做一次。只要简单功耗分析SPA能区分出倍点和点加操作密钥位就直接暴露了根本不用复杂的统计处理。即便把算法换成固定操作序列的Montgomery ladder点加和倍点不再依赖密钥位区分但每一轮中间值的具体数值仍和密钥有关。此时SPA失效了DPA或CPA依然有效。原因是功耗不仅和“做了哪类操作”有关还和“操作的数据内容”有关。数据相关功耗在硬件实现中尤其明显因为寄存器翻转是可重复、可测量的。2.3 SPA、DPA、CPA三种功耗分析思路的分工功耗分析一般分两大类简单功耗分析SPA和差分功耗分析DPA。SPA直接看一条或少数几条功耗轨迹从波形形状推断操作类型和密钥位。对未防护的ECC实现SPA往往已经能看出倍点和点加的节奏差异。不过SPA依赖高质量波形信噪比要足够好否则很难肉眼分辨。DPA则把大量轨迹按某个密钥假设分成两组比较两组的平均功耗差异。如果分组正确两组均值会出现明显偏差分组错误两组均值接近白噪声。CPA更进一步不再用分组平均而是对每个密钥假设计算预测功耗值然后与实测轨迹逐点求Pearson相关系数取绝对值最高峰对应的密钥候选作为结果。我在实验里用得最多的是CPA因为ECC的中间值模型比较灵活可以预测某个寄存器或总线上中间坐标的汉明重量。CPA本质上是一种“模型驱动”的攻击只要你选对中间值和功耗模型相关性就会很明显。下面一章就重点写实际操作从设备怎么搭开始一步步跑通整个流程。3. 实操流程从零搭建ECC硬件功耗分析实验3.1 设备选型不是越贵越好但采样率不能低做功耗分析不一定非要几百万的实验室设备入门用ChipWhisperer之类的开源平台完全够用。当时我用的是ChipWhisperer Lite加一块带ECC核的FPGA目标板总共成本控制在千元级别。如果你手头只有实验室通用示波器也会有办法但要做好信号同步和采集效率低的心理准备。关键参数有三个采样率、带宽和垂直分辨率。采样率至少要达到目标时钟频率的10倍以上。比如FPGA跑40MHz示波器或采集器至少要400MS/s才能看到比较完整的瞬态功耗波形。带宽方面功耗信号的绝大部分能量集中在几十到几百兆赫兹以内100MHz以上的带宽基本够用不必追求超高带宽。垂直分辨率建议不低于8位10位或12位更好。设备选型还有一个容易忽视的点采集器的输入阻抗和探头类型。普通无源探头能用但探头地线夹会引入很大噪声。更推荐用短地弹簧或差分探头。想省事就直接用ChipWhisperer自带的采样前端它把放大、滤波、触发做了集成对新手友好很多。3.2 板上取功耗信号串联采样电阻还是电流探头取功耗信号最常见的做法是在目标芯片的电源引脚串联一个小电阻。电流流过电阻时产生压降用示波器测量电阻两端电压就等价于测到了电流的波动。这个电阻叫采样电阻或shunt resistor。阻值要选得恰到好处太小了信号太弱太大了会拉低芯片供电电压。我当时试过1欧姆、10欧姆和33欧姆三个值。在3.3V供电、待机电流几十毫安的FPGA板上10欧姆电阻产生的压降大约几十到几百毫伏足够示波器清晰分辨同时又不会明显影响芯片工作。如果你用的是低功耗单片机或安全芯片待机电流可能只有几毫安10欧姆压降只有几十毫伏可以适当提高到100欧姆但一定要确认芯片供电电压余量足够。电流探头是另一种方案优点是不破坏供电回路也能测高频电流成分但价格贵低端型号的噪声也不小。做高精度DPA时我更喜欢电流探头加低噪声放大器的组合但入门阶段完全没必要。另外测量点越靠近芯片电源引脚越好尽量避开板上大容量去耦电容因为去耦电容会把高频功耗信号旁路掉导致你采到的信号被严重削波。3.3 触发与数据采集保证每一条波形都对得上采集功耗轨迹时最容易翻车的不是采样率而是触发。密码运算从开始到结束可能只有几万个时钟周期如果每次采集的起点不一致后续所有轨迹都无法对齐相关性分析会直接失败。最好的办法是在硬件设计里引出一个触发引脚在标量乘法开始前一两个周期拉高结束时拉低。没有硬件触发时我试过用输入数据的下降沿作为触发条件也能用但稳定性差一些。更糟糕的情况是目标系统里有操作系统或随机延时导致每次加密的起始时刻都在变化。这时候只能用后处理对齐比如先抓一段包含前导信号的完整波形再用互相关运算把所有轨迹对齐到同一参考点。采集过程本身也有一些思路值得说。一般来说至少要采几千条到几万条轨迹才能让统计相关性稳定下来。我通常先把单条轨迹长度控制在256KB以内用ChipWhisperer的Python接口批量采集存成numpy数组。内存不足时不存全轨迹只保存功耗模型对应时间点附近的一个小窗口这样分析速度会快很多。3.4 功耗模型与CPA计算把相关性算出来CPA的核心是构造预测功耗。我用的最简单模型是汉明重量也就是中间值二进制里1的个数。对于标量乘法中的某个中间坐标比如模乘结果的低32位我可以对每个猜测的密钥位组合计算这个中间值然后取它的汉明重量作为预测功耗。这条预测序列和实测功耗序列做相关运算就可以得到该密钥假设下的相关系数轨迹。Pearson相关系数公式不复杂但建议用现成库实现。我在Python里用scipy.stats.pearsonr或者直接用numpy.corrcoef循环枚举所有密钥候选保存每个候选的最大相关系数。密钥正确时相关系数会在某个采样点出现明显尖峰密钥错误时相关系数接近零。通过比较所有候选的峰值就能确定密钥位。选择中间值的位置非常讲究。对于ECC来说我习惯选择第二轮回合前或倍点后的坐标寄存器作为分析目标因为这个数据既依赖已知的基点P又依赖当前猜测的密钥比特而且会在固定时钟周期出现在总线上。如果选的位置太靠后前期的小错误会对预测产生累积偏差相关性反而会下降。初学者可以先从一个字节的中间值开始尝试跑通后再扩展到完整密钥。3.5 完整实验数据分析示例我在一次实验中对未防护的ECC FPGA实现采集了5000条轨迹每条轨迹记录了从触发开始到标量乘法结束共25000个采样点。对密钥的第0字节做CPA正确字节的相关系数最高达到0.42其他候选字节最高不超过0.1。这个对比非常明显用一条简单的max函数就能从256个候选里挑出正确字节。如果是一次完整恢复整个标量可以逐字节推进。先恢复第一个字节把结果作为已知前缀再计算后续字节的中间值重复CPA。项目实践下来未防护的P-256实现大约需要4到8万条轨迹才能稳定恢复全部32字节耗时主要取决于采集速度和存储带宽。换个更快的数据采集设备整个过程可以在几分钟内完成。为了方便观察我把每个密钥候选的最大相关系数画成柱状图。正确候选那条柱子会高出一大截视觉冲击感很强。这种图表在写项目报告或做内部演示时非常有用它直观地证明功耗泄漏确实存在且可以被程序化利用。4. 实战排错我踩过的坑和排查思路4.1 波形噪声大相关性完全出不来第一次做实验时我采到的波形毛刺特别多CPA结果无论密钥候选怎么选相关系数都只有0.05左右跟随机噪声差不多。排查后发现是示波器探头的地线太长加上实验桌上有开关电源的干扰。把地线换成短弹簧给开发板用线性稳压供电后信噪比立刻提升了几个量级。噪声消除还有几个细节值得注意。一是采样平均值设置如果密码运算可以重复执行且结果一致可以每条轨迹采集多次取平均把随机噪声压掉。二是对波形做简单低通滤波或中值滤波但滤波窗口不能太大否则会抹掉功耗尖峰。三是注意采集器和被测板共地接地点最好在采样电阻靠近芯片的一侧避免地回路引入额外噪声。现实中功耗信号里的确定性成分才是攻击需要的“信号”随机噪声只会拉低相关性。所以先降噪再分析顺序不能反。我在后续实验中都会留一条已知密钥的基线轨迹先验证采集系统能不能稳定重复地抓到同样的功耗峰再用真实密钥做盲恢复。4.2 波形对齐失败重采样与互相关有一次程序把触发信号接错了引脚导致采集到的每条轨迹起点前后抖动几十个采样点。CPA结果相关性极低因为同一个时间点在不同轨迹里对应的是不同操作阶段。肉眼看到波形似乎差不多但其实每次都错位了几个时钟周期。解决对齐问题我先是改回正确触发引脚重新采集一轮。如果触发信号实在没法改就用互相关对齐选择一条参考轨迹对其他轨迹做滑动互相关找到峰值位置作为偏移量然后把轨迹平移回去。这个方法对线性平移有效但如果时钟频率不稳定导致时间轴非线性扭曲就需要做动态时间规整。对齐是功耗分析的“基本功”。即使是正确触发的情况下采样时钟和目标时钟不同步也可能引起亚采样级别的抖动。通常我会在软件里对每条轨迹做一次粗略的峰值对齐找到功耗谱中最明显的那个尖峰位置统一对齐再做后续统计这样成功率稳定很多。4.3 正确密钥的相关系数并没有一骑绝尘CPA最让人崩溃的不是相关性太低而是有几个错误密钥候选的峰值和正确密钥差不多。这种情况我遇到过几次原因通常是功耗模型选择不够准。汉明重量模型假定功耗只和1的个数线性相关但真实芯片受布线长度、负载电容、同时翻转串扰影响不一定完全满足这个线性关系。解决方法是换成汉明距离模型。汉明距离考虑的是寄存器前后两个状态之间发生了多少位翻转更贴近CMOS动态功耗的物理机制。在ECC硬件里我可以把某个中间坐标在当前周期和前一周期的数值都算出来取二者异或后的汉明重量作为预测功耗。这一改相关系数的区分度立刻改善。另外要检查中间值的“时间位置”。如果预测的中间值出现在第100个周期但你只取了第110个周期附近的轨迹窗口相关性也会被稀释。这需要回到RTL仿真里确认寄存器的更新时钟沿然后把功耗模型预测值精确对齐到那个周期。4.4 常见问题速查表我把实操中遇到的高频问题整理成了一张表方便你在排查时直接对照。问题表现可能原因处理方案波形毛刺多信噪比差探头地线过长、外部电源干扰短地弹簧、线性稳压供电、共地良好轨迹起点抖动CPA失效触发信号不可靠或未接增加硬件触发或用互相关对齐正确候选相关系数不高功耗模型不准改用汉明距离模型检查中间值位置错误候选也出现尖峰中间值选择偏移一个周期结合RTL仿真确定寄存器更新时间采集速度太慢全波形存储导致IO瓶颈只保存目标时间窗口批量采集每次测量相关性不稳定环境温度或电压漂移实验前预热使用稳压源控制室温这张表看着简单每一条背后都是一整天的排查。尤其是触发问题和功耗模型问题最容易绕弯建议优先排查。5. 加固方案如何避免ECC硬件变成筛子5.1 算法级随机化标量盲化和基点盲化功耗分析之所以有效是因为相同的密钥和相同的数据会产生重复的功耗模式。防护的核心思路就是“打乱这种重复性”。最常用的算法级方法之一是标量盲化给标量k加上一个随机数r乘以曲线的阶n得到k k rn然后计算kP。由于rnP是无穷远点结果和kP完全一致但每次计算中的实际标量都不同中间值轨迹也变得各不相同。另一种是基点盲化在计算开始时随机挑选一个盲化点R先计算P P R然后计算kP最后再从结果中减去kR。这样每次使用的基点都不同攻击者无法预知中间值常规CPA的功耗模型就失效了。这两种方法实现代价不一样标量盲化增加了标量的位宽计算量略有上升基点盲化多了一次点乘需要额外运算。算法级随机化对SPA和DPA都有很强的抑制作用。我把这类防护加到同一份ECC硬件代码里后再做CPA正确密钥的相关系数从0.42掉到了0.06以下基本无法区分。不过要注意随机数生成器的质量如果随机数熵不够或可预测盲化防护会退化成纸老虎。5.2 操作序列固定统一乘法与Montgomery ladderSPA攻击依赖“倍点和点加操作模式不同”这个特征。只要想办法让每个密钥位都执行同样数量和类型的操作SPA就失效了。Montgomery ladder就是非常经典的做法。它每轮都会同时执行一次倍点和一次点加执行流程不依赖密钥位是0还是1从功耗波形上看操作序列完全均匀。还有一类方法是统一点公式让点加和倍点在计算形式上尽量一致减少两种操作在微架构上的功耗差异。但统一公式通常会增加计算量而且如果ALU的微码序列仍然有区别简单功耗分析还是可能看出端倪。所以在硬件设计时要确保“操作序列均匀”和“微架构功耗均匀”同时成立光靠公式统一还不够。常数时间实现也是必须的。如果某个条件分支的执行时间和数据相关攻击者可以通过时间侧信道继续提取信息。比如在MUL里乘数中有0会提前退出循环就属于典型的不安全写法。做硬件RTL时要保证所有路径都在固定周期内完成。5.3 硬件实现层掩码、隐藏与随机时钟算法级随机化能对付简单方式但更高阶的攻击仍可能通过联合分析多时刻功耗来破解。硬件层常用掩码技术将敏感中间值拆分成多个随机份额运算过程始终不暴露真实值。门级掩码需要设计专门的逻辑单元面积和功耗开销都比较大但安全性提升明显。隐藏技术的思路则是让功耗与数据无关。比如双轨预充电逻辑每个信号都同时存在正逻辑和负逻辑两条线无论数据是0还是1总正好一个翻转芯片整体功耗几乎恒定。这种电路能把信号相关功耗压到极低但代价是面积和功耗直接翻一倍通常只用在安全等级极高的芯片里。随机时钟和随机延时插入也很有用。即使攻击者采集到了功耗轨迹如果密码运算的时钟周期随机抖动所有中间值出现在不同时间点轨迹对齐就会变得困难。实现时可以在硬件里加入可配置的延时单元或时钟随机扰乱模块。不过随机时钟会降低吞吐量需要根据应用场景平衡。5.4 验证防护效果重新跑一次CPA就知道了加防护之后我习惯先做一次攻击前后对比不能只凭“感觉安全”就收工。把同一份标量乘法RTL分别编译成未防护和防护两个版本用同样的采集平台和CPA脚本分析记录正确候选与次优候选的相关系数差距。如果差距明显缩小说明需要更多轨迹才能攻击成功。更进一步可以绘制“轨迹数vs恢复成功率”曲线。未防护版本可能几百条轨迹就能达到90%成功率防护版本可能几百万条轨迹也无法恢复。这条曲线是衡量防护等级最直观的数据。另一个简单指标是“最大相关系数”防护良好的实现中任何密钥候选的最大相关系数都应该接近0.05以内。需要注意的是验证不是跑一次就结束。环境和工具链都会影响结果。我通常会在不同温度、不同供电电压下各跑一轮确认防护的稳定性。毕竟侧信道防护最怕的就是“某个特定条件下泄漏恢复”那种隐蔽漏洞在实际产品里更难被发现。6. 最后分享一点个人经验6.1 做功耗分析先别急着堆设备如果你刚刚起步我的第一建议不是马上去买高端示波器和高带宽电流探头而是先把一套开源工具链跑通。用ChipWhisperer加一块简单的FPGA开发板把触发、采集、对齐、功耗模型、CPA脚本全部走一遍这个过程能帮你建立对信号链路的直觉。等基本流程稳定了再考虑升级硬件。原因很简单功耗分析核心是“数据相关功耗”这个概念而不是设备精度。设备再好如果中间值选错时间点、功耗模型选错类型、触发信号不稳照样分析不出来。反过来用入门设备把方法论吃透换到更复杂的芯片上时你才知道瓶颈到底在采集带宽、噪声还是算法复杂度。6.2 侧信道防护是一个系统工程不是加个掩码就完事我最大的体会是侧信道安全不能靠单一手段。标量盲化、操作序列固定、门级掩码、随机时钟这些措施单独使用都可能被更高阶的攻击绕开。真正稳妥的做法是在算法、硬件架构、版图布局和系统流程多个层面同时设计再经过严格的攻击验证。防护不是加一个部件而是一个从需求到测试都贯穿的工程过程。另外做这类实验一定要有合法授权只在自有设备或实验平台上进行。侧信道分析技能是中性的既可以帮助厂商发现漏洞也可以被恶意利用。尊重知识产权和数据安全是技术人最基本的底线。希望这篇实战记录能帮你少踩几个坑也让你在保护硬件密码实现时多一分判断力。
ECC硬件功耗分析实战：从CPA原理到防护方案
第一次接触ECC硬件功耗分析的时候我差点以为用示波器夹两根线就能把私钥读出来。结果连续一周都在跟噪声、触发信号和波形对齐搏斗。后来才想明白标题里的Power Analysis、ECC、Hardware Implementations三个词每一个都足够撑起一门课。这篇文章打算从一个踩过坑的角度聊聊怎么真正动手做一套ECC硬件实现的功耗分析实验包括平台怎么搭、曲线怎么采、相关性怎么算、遇到问题怎么排以及防护方案到底有没有用。内容会尽量贴近实操适合正在做硬件安全、侧信道攻击或密码芯片验证的工程师也适合想入门的同学照着把流程跑通。1. 项目背景为什么ECC硬件功耗分析值得专门写一篇1.1 椭圆曲线密码在硬件里的江湖地位椭圆曲线密码在这几年基本成了安全芯片和物联网终端的标配。原因不复杂同等安全强度下ECC的密钥长度远小于RSA。160位的椭圆曲线密钥大致能对标1024位的RSA256位曲线可以对标3072位RSA。对于智能卡、车规芯片、TEE模块这些面积和功耗都敏感的场景少存几个字节、少算几次模幂就是实打实的成本优势。硬件实现ECC时核心运算落在标量乘法上也就是计算kP其中k是私钥标量P是椭圆曲线上的基点。这个运算看起来只有一行公式落到RTL电路里却涉及大量有限域模加、模乘、模逆以及点加、倍点操作。硬件实现的执行速度快但功耗特征也比软件更规整、更容易被采集。如果设计者只在算法层面做了正确性设计没做侧信道防护那么功耗轨迹里往往藏着密钥的全部信息。我最初接触这个课题时目标很简单在一块FPGA上跑一个未加防护的P-256标量乘法尝试用功耗分析把标量k恢复出来。项目名称叫Power Analysis of ECC Hardware Implementations说白了就是把“功耗分析”和“ECC硬件实现”这两件事绑在一起验证侧信道风险到底有多真实。1.2 先把概念对齐这个ECC不是内存校验码“ECC”这个名字很容易引起误会。搜索时经常蹦出“ecc校验”或者“SAP ECC basis”这两个东西跟椭圆曲线密码完全不是一个世界。ecc校验是内存纠错码解决的是存储位翻转问题SAP ECC basis是企业管理软件里的平台组件跟密码学没有任何关系。我在这篇里提到的ECC单指Elliptic Curve Cryptography椭圆曲线密码。把名字分清楚不是小事。我们当时做项目调研有位同事拿着内存纠错码的资料研究了半天还以为系统里已经内置了抗攻击机制。其实密码学里的ECC和内存纠错只是共享了同一个缩写的缩略词。实际做硬件功耗分析时我关注的是椭圆曲线群运算在设备运行过程中产生的功耗旁路信息而不是内存错误检查和纠正的状态机。命名虽然容易混淆但原理和防护思路差异巨大。内存ecc校验关心数据完整性密码学ECC关心机密性。功耗分析攻击针对的是后者目标是利用物理泄漏还原私钥。所以后面所有内容都围绕椭圆曲线密码展开不再做歧义讨论。1.3 功耗分析解决的是什么问题密码算法设计时大家默认攻击者只能看到输入输出。但真实物理芯片不同芯片工作时要耗电微电子开关活动会在电源引脚上造成微小的电流波动。加密过程不同时刻的中间值不同开关翻转数量也就不同于是功耗轨迹和中间值之间产生了相关性。功耗分析就是利用这种相关性来推断密钥的方法。和故障注入、电磁侧信道、缓存侧信道相比功耗分析的优点是门槛相对低一块示波器加一根采样电阻就能采集到信号缺点是噪声大、波形多、对齐麻烦而且一旦遇到合格的防护措施基本分析会立刻失效。我做这个项目的核心目标就是搞清楚“ECC硬件实现到底泄漏了多少”。实测结果比想象中更直接对于一款没有加任何防护的ECC FPGA实现采集几千条功耗轨迹之后通过CPA相关性能量分析恢复标量k的前几十位密钥成功率接近百分之百。这让我意识到硬件上的密码实现如果不做侧信道设计私钥几乎是裸奔的。2. 功耗分析到底在分析什么2.1 泄漏源头CMOS功耗与数据翻转的关系现代数字芯片绝大多数基于CMOS工艺。CMOS电路的主要功耗来源是动态功耗也就是逻辑节点发生0到1或1到0翻转时对负载电容充放电产生的功耗。一次翻转消耗的能量大致可以写成E 0.5 × C × V²。在这个公式里C和V对特定芯片来说是固定常数可变的是翻转次数。如果某条数据总线从0x00变成0xFF8个比特同时翻转比从0x00变成0x01多消耗不少能量。这种“翻转越多功耗越高”的现象就是功耗模型的基础。侧信道分析里最经典的汉明重量模型认为功耗和中间值二进制表示中1的个数成正比更精细一点的汉明距离模型则考虑相邻时钟周期内寄存器新旧数值之间逐比特翻转的数量。ECC硬件实现中大量数据在寄存器、ALU和存储器之间搬移。每次模乘、点加、倍点都会产生大量确定的中间值。攻击者只要知道或猜出一部分中间值就能用功耗模型去匹配实测功耗曲线。如果某一位密钥猜对了预测功耗和实测功耗的相关性会明显高于猜错的情况。这也解释了为什么“数据相关功耗”是侧信道攻击的核心前提。2.2 ECC硬件实现里最容易被盯上的运算标量乘法ECC的加密、签名、密钥交换底层都是标量乘法。签名算法ECDSA中的私钥k会直接参与计算kGECDH密钥交换中私钥也以标量乘法的方式作用在对方公钥上。可以说保护了标量乘法就保护了ECC的大部分安全性。标量乘法不是一步算完的它由若干轮点加和倍点组成。比如最简单的从左到右二进制扫描算法从最高位开始每轮先对结果做倍点如果当前密钥位是1再执行一次点加。这个流程有一个致命特征密钥位为1时多做一次点加为0时少做一次。只要简单功耗分析SPA能区分出倍点和点加操作密钥位就直接暴露了根本不用复杂的统计处理。即便把算法换成固定操作序列的Montgomery ladder点加和倍点不再依赖密钥位区分但每一轮中间值的具体数值仍和密钥有关。此时SPA失效了DPA或CPA依然有效。原因是功耗不仅和“做了哪类操作”有关还和“操作的数据内容”有关。数据相关功耗在硬件实现中尤其明显因为寄存器翻转是可重复、可测量的。2.3 SPA、DPA、CPA三种功耗分析思路的分工功耗分析一般分两大类简单功耗分析SPA和差分功耗分析DPA。SPA直接看一条或少数几条功耗轨迹从波形形状推断操作类型和密钥位。对未防护的ECC实现SPA往往已经能看出倍点和点加的节奏差异。不过SPA依赖高质量波形信噪比要足够好否则很难肉眼分辨。DPA则把大量轨迹按某个密钥假设分成两组比较两组的平均功耗差异。如果分组正确两组均值会出现明显偏差分组错误两组均值接近白噪声。CPA更进一步不再用分组平均而是对每个密钥假设计算预测功耗值然后与实测轨迹逐点求Pearson相关系数取绝对值最高峰对应的密钥候选作为结果。我在实验里用得最多的是CPA因为ECC的中间值模型比较灵活可以预测某个寄存器或总线上中间坐标的汉明重量。CPA本质上是一种“模型驱动”的攻击只要你选对中间值和功耗模型相关性就会很明显。下面一章就重点写实际操作从设备怎么搭开始一步步跑通整个流程。3. 实操流程从零搭建ECC硬件功耗分析实验3.1 设备选型不是越贵越好但采样率不能低做功耗分析不一定非要几百万的实验室设备入门用ChipWhisperer之类的开源平台完全够用。当时我用的是ChipWhisperer Lite加一块带ECC核的FPGA目标板总共成本控制在千元级别。如果你手头只有实验室通用示波器也会有办法但要做好信号同步和采集效率低的心理准备。关键参数有三个采样率、带宽和垂直分辨率。采样率至少要达到目标时钟频率的10倍以上。比如FPGA跑40MHz示波器或采集器至少要400MS/s才能看到比较完整的瞬态功耗波形。带宽方面功耗信号的绝大部分能量集中在几十到几百兆赫兹以内100MHz以上的带宽基本够用不必追求超高带宽。垂直分辨率建议不低于8位10位或12位更好。设备选型还有一个容易忽视的点采集器的输入阻抗和探头类型。普通无源探头能用但探头地线夹会引入很大噪声。更推荐用短地弹簧或差分探头。想省事就直接用ChipWhisperer自带的采样前端它把放大、滤波、触发做了集成对新手友好很多。3.2 板上取功耗信号串联采样电阻还是电流探头取功耗信号最常见的做法是在目标芯片的电源引脚串联一个小电阻。电流流过电阻时产生压降用示波器测量电阻两端电压就等价于测到了电流的波动。这个电阻叫采样电阻或shunt resistor。阻值要选得恰到好处太小了信号太弱太大了会拉低芯片供电电压。我当时试过1欧姆、10欧姆和33欧姆三个值。在3.3V供电、待机电流几十毫安的FPGA板上10欧姆电阻产生的压降大约几十到几百毫伏足够示波器清晰分辨同时又不会明显影响芯片工作。如果你用的是低功耗单片机或安全芯片待机电流可能只有几毫安10欧姆压降只有几十毫伏可以适当提高到100欧姆但一定要确认芯片供电电压余量足够。电流探头是另一种方案优点是不破坏供电回路也能测高频电流成分但价格贵低端型号的噪声也不小。做高精度DPA时我更喜欢电流探头加低噪声放大器的组合但入门阶段完全没必要。另外测量点越靠近芯片电源引脚越好尽量避开板上大容量去耦电容因为去耦电容会把高频功耗信号旁路掉导致你采到的信号被严重削波。3.3 触发与数据采集保证每一条波形都对得上采集功耗轨迹时最容易翻车的不是采样率而是触发。密码运算从开始到结束可能只有几万个时钟周期如果每次采集的起点不一致后续所有轨迹都无法对齐相关性分析会直接失败。最好的办法是在硬件设计里引出一个触发引脚在标量乘法开始前一两个周期拉高结束时拉低。没有硬件触发时我试过用输入数据的下降沿作为触发条件也能用但稳定性差一些。更糟糕的情况是目标系统里有操作系统或随机延时导致每次加密的起始时刻都在变化。这时候只能用后处理对齐比如先抓一段包含前导信号的完整波形再用互相关运算把所有轨迹对齐到同一参考点。采集过程本身也有一些思路值得说。一般来说至少要采几千条到几万条轨迹才能让统计相关性稳定下来。我通常先把单条轨迹长度控制在256KB以内用ChipWhisperer的Python接口批量采集存成numpy数组。内存不足时不存全轨迹只保存功耗模型对应时间点附近的一个小窗口这样分析速度会快很多。3.4 功耗模型与CPA计算把相关性算出来CPA的核心是构造预测功耗。我用的最简单模型是汉明重量也就是中间值二进制里1的个数。对于标量乘法中的某个中间坐标比如模乘结果的低32位我可以对每个猜测的密钥位组合计算这个中间值然后取它的汉明重量作为预测功耗。这条预测序列和实测功耗序列做相关运算就可以得到该密钥假设下的相关系数轨迹。Pearson相关系数公式不复杂但建议用现成库实现。我在Python里用scipy.stats.pearsonr或者直接用numpy.corrcoef循环枚举所有密钥候选保存每个候选的最大相关系数。密钥正确时相关系数会在某个采样点出现明显尖峰密钥错误时相关系数接近零。通过比较所有候选的峰值就能确定密钥位。选择中间值的位置非常讲究。对于ECC来说我习惯选择第二轮回合前或倍点后的坐标寄存器作为分析目标因为这个数据既依赖已知的基点P又依赖当前猜测的密钥比特而且会在固定时钟周期出现在总线上。如果选的位置太靠后前期的小错误会对预测产生累积偏差相关性反而会下降。初学者可以先从一个字节的中间值开始尝试跑通后再扩展到完整密钥。3.5 完整实验数据分析示例我在一次实验中对未防护的ECC FPGA实现采集了5000条轨迹每条轨迹记录了从触发开始到标量乘法结束共25000个采样点。对密钥的第0字节做CPA正确字节的相关系数最高达到0.42其他候选字节最高不超过0.1。这个对比非常明显用一条简单的max函数就能从256个候选里挑出正确字节。如果是一次完整恢复整个标量可以逐字节推进。先恢复第一个字节把结果作为已知前缀再计算后续字节的中间值重复CPA。项目实践下来未防护的P-256实现大约需要4到8万条轨迹才能稳定恢复全部32字节耗时主要取决于采集速度和存储带宽。换个更快的数据采集设备整个过程可以在几分钟内完成。为了方便观察我把每个密钥候选的最大相关系数画成柱状图。正确候选那条柱子会高出一大截视觉冲击感很强。这种图表在写项目报告或做内部演示时非常有用它直观地证明功耗泄漏确实存在且可以被程序化利用。4. 实战排错我踩过的坑和排查思路4.1 波形噪声大相关性完全出不来第一次做实验时我采到的波形毛刺特别多CPA结果无论密钥候选怎么选相关系数都只有0.05左右跟随机噪声差不多。排查后发现是示波器探头的地线太长加上实验桌上有开关电源的干扰。把地线换成短弹簧给开发板用线性稳压供电后信噪比立刻提升了几个量级。噪声消除还有几个细节值得注意。一是采样平均值设置如果密码运算可以重复执行且结果一致可以每条轨迹采集多次取平均把随机噪声压掉。二是对波形做简单低通滤波或中值滤波但滤波窗口不能太大否则会抹掉功耗尖峰。三是注意采集器和被测板共地接地点最好在采样电阻靠近芯片的一侧避免地回路引入额外噪声。现实中功耗信号里的确定性成分才是攻击需要的“信号”随机噪声只会拉低相关性。所以先降噪再分析顺序不能反。我在后续实验中都会留一条已知密钥的基线轨迹先验证采集系统能不能稳定重复地抓到同样的功耗峰再用真实密钥做盲恢复。4.2 波形对齐失败重采样与互相关有一次程序把触发信号接错了引脚导致采集到的每条轨迹起点前后抖动几十个采样点。CPA结果相关性极低因为同一个时间点在不同轨迹里对应的是不同操作阶段。肉眼看到波形似乎差不多但其实每次都错位了几个时钟周期。解决对齐问题我先是改回正确触发引脚重新采集一轮。如果触发信号实在没法改就用互相关对齐选择一条参考轨迹对其他轨迹做滑动互相关找到峰值位置作为偏移量然后把轨迹平移回去。这个方法对线性平移有效但如果时钟频率不稳定导致时间轴非线性扭曲就需要做动态时间规整。对齐是功耗分析的“基本功”。即使是正确触发的情况下采样时钟和目标时钟不同步也可能引起亚采样级别的抖动。通常我会在软件里对每条轨迹做一次粗略的峰值对齐找到功耗谱中最明显的那个尖峰位置统一对齐再做后续统计这样成功率稳定很多。4.3 正确密钥的相关系数并没有一骑绝尘CPA最让人崩溃的不是相关性太低而是有几个错误密钥候选的峰值和正确密钥差不多。这种情况我遇到过几次原因通常是功耗模型选择不够准。汉明重量模型假定功耗只和1的个数线性相关但真实芯片受布线长度、负载电容、同时翻转串扰影响不一定完全满足这个线性关系。解决方法是换成汉明距离模型。汉明距离考虑的是寄存器前后两个状态之间发生了多少位翻转更贴近CMOS动态功耗的物理机制。在ECC硬件里我可以把某个中间坐标在当前周期和前一周期的数值都算出来取二者异或后的汉明重量作为预测功耗。这一改相关系数的区分度立刻改善。另外要检查中间值的“时间位置”。如果预测的中间值出现在第100个周期但你只取了第110个周期附近的轨迹窗口相关性也会被稀释。这需要回到RTL仿真里确认寄存器的更新时钟沿然后把功耗模型预测值精确对齐到那个周期。4.4 常见问题速查表我把实操中遇到的高频问题整理成了一张表方便你在排查时直接对照。问题表现可能原因处理方案波形毛刺多信噪比差探头地线过长、外部电源干扰短地弹簧、线性稳压供电、共地良好轨迹起点抖动CPA失效触发信号不可靠或未接增加硬件触发或用互相关对齐正确候选相关系数不高功耗模型不准改用汉明距离模型检查中间值位置错误候选也出现尖峰中间值选择偏移一个周期结合RTL仿真确定寄存器更新时间采集速度太慢全波形存储导致IO瓶颈只保存目标时间窗口批量采集每次测量相关性不稳定环境温度或电压漂移实验前预热使用稳压源控制室温这张表看着简单每一条背后都是一整天的排查。尤其是触发问题和功耗模型问题最容易绕弯建议优先排查。5. 加固方案如何避免ECC硬件变成筛子5.1 算法级随机化标量盲化和基点盲化功耗分析之所以有效是因为相同的密钥和相同的数据会产生重复的功耗模式。防护的核心思路就是“打乱这种重复性”。最常用的算法级方法之一是标量盲化给标量k加上一个随机数r乘以曲线的阶n得到k k rn然后计算kP。由于rnP是无穷远点结果和kP完全一致但每次计算中的实际标量都不同中间值轨迹也变得各不相同。另一种是基点盲化在计算开始时随机挑选一个盲化点R先计算P P R然后计算kP最后再从结果中减去kR。这样每次使用的基点都不同攻击者无法预知中间值常规CPA的功耗模型就失效了。这两种方法实现代价不一样标量盲化增加了标量的位宽计算量略有上升基点盲化多了一次点乘需要额外运算。算法级随机化对SPA和DPA都有很强的抑制作用。我把这类防护加到同一份ECC硬件代码里后再做CPA正确密钥的相关系数从0.42掉到了0.06以下基本无法区分。不过要注意随机数生成器的质量如果随机数熵不够或可预测盲化防护会退化成纸老虎。5.2 操作序列固定统一乘法与Montgomery ladderSPA攻击依赖“倍点和点加操作模式不同”这个特征。只要想办法让每个密钥位都执行同样数量和类型的操作SPA就失效了。Montgomery ladder就是非常经典的做法。它每轮都会同时执行一次倍点和一次点加执行流程不依赖密钥位是0还是1从功耗波形上看操作序列完全均匀。还有一类方法是统一点公式让点加和倍点在计算形式上尽量一致减少两种操作在微架构上的功耗差异。但统一公式通常会增加计算量而且如果ALU的微码序列仍然有区别简单功耗分析还是可能看出端倪。所以在硬件设计时要确保“操作序列均匀”和“微架构功耗均匀”同时成立光靠公式统一还不够。常数时间实现也是必须的。如果某个条件分支的执行时间和数据相关攻击者可以通过时间侧信道继续提取信息。比如在MUL里乘数中有0会提前退出循环就属于典型的不安全写法。做硬件RTL时要保证所有路径都在固定周期内完成。5.3 硬件实现层掩码、隐藏与随机时钟算法级随机化能对付简单方式但更高阶的攻击仍可能通过联合分析多时刻功耗来破解。硬件层常用掩码技术将敏感中间值拆分成多个随机份额运算过程始终不暴露真实值。门级掩码需要设计专门的逻辑单元面积和功耗开销都比较大但安全性提升明显。隐藏技术的思路则是让功耗与数据无关。比如双轨预充电逻辑每个信号都同时存在正逻辑和负逻辑两条线无论数据是0还是1总正好一个翻转芯片整体功耗几乎恒定。这种电路能把信号相关功耗压到极低但代价是面积和功耗直接翻一倍通常只用在安全等级极高的芯片里。随机时钟和随机延时插入也很有用。即使攻击者采集到了功耗轨迹如果密码运算的时钟周期随机抖动所有中间值出现在不同时间点轨迹对齐就会变得困难。实现时可以在硬件里加入可配置的延时单元或时钟随机扰乱模块。不过随机时钟会降低吞吐量需要根据应用场景平衡。5.4 验证防护效果重新跑一次CPA就知道了加防护之后我习惯先做一次攻击前后对比不能只凭“感觉安全”就收工。把同一份标量乘法RTL分别编译成未防护和防护两个版本用同样的采集平台和CPA脚本分析记录正确候选与次优候选的相关系数差距。如果差距明显缩小说明需要更多轨迹才能攻击成功。更进一步可以绘制“轨迹数vs恢复成功率”曲线。未防护版本可能几百条轨迹就能达到90%成功率防护版本可能几百万条轨迹也无法恢复。这条曲线是衡量防护等级最直观的数据。另一个简单指标是“最大相关系数”防护良好的实现中任何密钥候选的最大相关系数都应该接近0.05以内。需要注意的是验证不是跑一次就结束。环境和工具链都会影响结果。我通常会在不同温度、不同供电电压下各跑一轮确认防护的稳定性。毕竟侧信道防护最怕的就是“某个特定条件下泄漏恢复”那种隐蔽漏洞在实际产品里更难被发现。6. 最后分享一点个人经验6.1 做功耗分析先别急着堆设备如果你刚刚起步我的第一建议不是马上去买高端示波器和高带宽电流探头而是先把一套开源工具链跑通。用ChipWhisperer加一块简单的FPGA开发板把触发、采集、对齐、功耗模型、CPA脚本全部走一遍这个过程能帮你建立对信号链路的直觉。等基本流程稳定了再考虑升级硬件。原因很简单功耗分析核心是“数据相关功耗”这个概念而不是设备精度。设备再好如果中间值选错时间点、功耗模型选错类型、触发信号不稳照样分析不出来。反过来用入门设备把方法论吃透换到更复杂的芯片上时你才知道瓶颈到底在采集带宽、噪声还是算法复杂度。6.2 侧信道防护是一个系统工程不是加个掩码就完事我最大的体会是侧信道安全不能靠单一手段。标量盲化、操作序列固定、门级掩码、随机时钟这些措施单独使用都可能被更高阶的攻击绕开。真正稳妥的做法是在算法、硬件架构、版图布局和系统流程多个层面同时设计再经过严格的攻击验证。防护不是加一个部件而是一个从需求到测试都贯穿的工程过程。另外做这类实验一定要有合法授权只在自有设备或实验平台上进行。侧信道分析技能是中性的既可以帮助厂商发现漏洞也可以被恶意利用。尊重知识产权和数据安全是技术人最基本的底线。希望这篇实战记录能帮你少踩几个坑也让你在保护硬件密码实现时多一分判断力。