面向典型处理器架构的代码级侧信道仿真特性研究*

杨 光, 李东方, 沈 炜, 王 纪, 刘诗宇

北京计算机技术及应用研究所, 北京100854

1 引言

侧信道分析[1]是一类基于密码实现漏洞而发起的攻击方法,以最为经典的能量侧信道分析为例,其基本原理是CPU 处理寄存器、总线中数据比特翻转的能量变化可能泄漏数据, 所以电路功耗与写入寄存器数据的汉明重量近似呈线性相关[2].如图1 所示, 通过分析来自目标设备的功耗轨迹或电磁辐射信号以及相应的明文和密文数据集合, 侧信道分析从硬件系统中提取加密密钥从而破解目标设备.与其它方法相比,侧信道分析具有攻击力度大、隐蔽性强、通用性高等优点, 对密码实现的实际物理安全性构成了极大威胁,引起了学术界、工业界和测评界的广泛关注.

图1 侧信道分析示意图Figure 1 Overall workflow of side channel analysis

在实际的工程实践中, 对密码产品的侧信道评估往往需要使用昂贵的专用采集和分析软件, 对人员专业素质和经验有较高要求.受制于接口调试、物理泄漏侧信道筛选等众多软硬件协同问题和实际工程经验限制, 对待分析设备的抗侧信道能力评估将经历算法设计-代码实现-编译调试-物理侧信道信息采集-侧信道分析与评估等若干步骤, 此外, 关于侧信道分析的加密算法评估通常在产品设计验证周期的末尾执行,如果存在安全缺陷, 将对产品实际推出时间产生相当大的影响.

传统的侧信道安全性评估方法主要通过在实际芯片或设备上采集和测量泄漏信息来评估侧信道风险,这种评估方案存在以下特点:

(1) 需要大量硬件采集设备, 购置成本高

对密码产品的侧信道安全性评估需要硬件采集设备支持, 如高精度示波器、电磁/电流探头、信号滤波器等, 这些硬件采集设备价格较为昂贵, 且配置项复杂.以国外某侧信道设备提供商产品为例, 其基础侧信道评估设备售价数百万人民币, 若进一步考虑测试人员的进阶培训费用, 整体购置成本将更高.

(2) 物理采集数据, 噪声影响分析结果

由于使用物理条件限制, 通过硬件采集设备测量的物理量不可避免地含有噪声干扰, 这将增加后续统计分析的样本观测量和计算量, 并且对算法的精确性和鲁棒性也提出了更高的要求.因此, 由于物理量统计特性和未知的噪声特点, 对实际采集得到的电磁泄漏或功耗轨迹需要使用多种复杂的分析手段, 对攻击算法选择和人员经验提出了更高的要求.

(3) 耗费人力物力, 评估周期较长

在工程实践中对待测设备的侧信道安全性评估常受软硬件协同问题和人员专业经验限制, 需要根据目标待测设备对采集硬件和分析软件多次适配调试, 消耗人力物力, 评估周期通常延续数周.从整体上看, 整个测评流程靠近设计测试周期的末端, 一旦检测出存在侧信道安全隐患, 将对整个密码产品设计开发及测试进度产生很大影响.

(4) 泄漏源头不可知, 依赖人员经验

传统的侧信道安全性评估依靠实际测量的侧信道物理量进行分析与评估, 对泄漏源头的定位局限在实际探测的物理量层面, 需要根据待测算法、待测设备实现特征和以往经验, 推测导致泄漏的实现细节, 无法准确将泄漏源头定位至具体的软件源代码.

为了解决传统侧信道分析依赖硬件采集设备、检测流程靠后等问题, 学术界提出代码级侧信道仿真分析技术, 其基本原理是通过监测记录密码软件代码在处理器运行期间的内存地址、寄存器值等信息, 模拟代码执行过程中可能发生的泄漏.2016 年, Bos 等人[3]提出差分计算攻击(differential computation analysis, DCA) 用于破解Chow 等人提出的白盒密码方案[4], 利用动态二进制工具框产生软件执行能量迹(如关于被访问内存地址的信息), 该方法能够自动化从白盒实现中提取密钥信息, 无需了解白盒设计的特定知识, 速度更快, 本质上可以看做软件版本的差分能量攻击(differential power analysis, DPA)[1].Allibert 等人[5]同样使用动态二进制插桩工具DBI 进行一阶和二阶差分计算攻击.2018 年, Bouvet 等人[6]使用动态调试工具对运行在X86 处理器上密码软件的寄存器信息进行检测, 并能够成功在仿真能量迹上检测出泄漏点, 并定位泄漏位置至汇编代码甚至源代码.Facon 等[7]通过代码调试器采集记录在代码执行过程中发生的所有位修改(寄存器、内存内容、标志、程序计数器) 作为能量迹的仿真模拟, 能够直接访问变量的值.Weiser 等人[8]提出基于地址的能量迹分析框架, 用于检测程序二进制文件中的基于地址的侧信道泄漏.通过了解相关工作可以发现, 使用代码级侧信道仿真分析技术, 仿真生成的能量迹没有物理采集噪声的影响, 无需根据目标设备假设泄漏模型, 能够将侧信道安全性评估在检测流程中提前, 并允许在软件开发过程中同时加入侧信道安全性评估, 该类攻击方法框架见图2.

图2 代码级侧信道仿真分析技术示意图Figure 2 Overall workflow of code level side channel simulation

综合对比传统侧信道分析和代码级侧信道仿真分析技术, 可总结代码级侧信道仿真分析技术具有如下优点, 详情见表1.

表1 传统侧信道评估和代码级侧信道仿真分析的对比Table 1 Comparison between side channel analysis and code level side channel simulation

(1) 节省测试成本.相较于传统的侧信道评估方法(依赖检测硬件和评估软件), 本技术无需购置昂贵采集硬件设备, 只需在普通计算机上即可进行快速仿真和测试.

(2) 分析结果更精确.相较于物理硬件采集, 使用软件仿真可以消除噪声(物理采集不可避免带来噪声), 从而提高准确性并减少采集数据量.

(3) 加快开发进度.传统侧信道评估方法检测流程靠后, 本技术无需频繁软硬件调试, 能够加快测试进度, 做到开发与检测同时迭代进行.

(4) 泄漏代码位置可定位.相较于传统侧信道评估方法, 本技术可直接由能量迹泄漏点反向定位至存在泄漏风险的源代码所在行, 做到泄漏代码的精确定位.

(5) 可跨平台.只需根据目标处理器架构交叉编译源代码, 即可仿真目标处理器架构上的泄漏特性.

然而, 已有的代码级侧信道仿真分析研究成果多局限于单一处理器架构上, 在多种处理器架构上的研究成果不足, 尚未见到对主流多种处理架构的代码级侧信道仿真有效性评估结果.因此, 本文在已有研究基础上, 在X86、ARM、MIPS、PowerPC、SPARC 等5 种主流处理器架构方面进行拓展, 利用代码交叉编译及处理器虚拟化技术, 探究对比在不同处理器架构下代码级侧信道仿真的特性.

2 基于仿真的C 代码级侧信道泄漏能量迹采集

在实际的侧信道评估中, 需要通过专门的采集设备测量被测设备的电磁或功耗曲线等物理量从而识别分析潜在的信息泄漏, 该过程耗时且具有挑战性.首先, 需要采集设备(示波器、探头、信号放大器等), 且要求技术人员具备相应的理论知识和实操经验.其次, 要评估的代码需要嵌入到最终产品或评估板上, 评估流程靠后, 对开发完成度要求较高.

本文采用一种基于仿真模拟的C 代码级侧信道泄漏能量迹采集技术, 技术框架见图3.具体方法可以细分为以下几个步骤:

图3 代码级侧信道泄漏能量迹采集流程图Figure 3 Detailed workflow of code level side channel simulation

步骤一: 给定目标算法的C 代码实现, 确定程序输入输出接口.多次变换程序输入, 动态执行程序文件, 以记录在不同输入条件下的寄存器值变化情况.

步骤二: 对目标代码进行交叉编译.可根据目标实现架构使用GCC (GNU 编译器套件) 家族编译器对目标实现进行编译, 并附上调试信息.编译完成后, 将生成二进制可执行程序.

步骤三: 根据处理器目标架构的不同, 搭建QEMU (quick EMUlator) 处理器仿真环境, 在宿主处理器上仿真目标处理器, 使交叉编译后的程序文件能够运行在宿主处理器上.

步骤四: 使用调试器汇编级调试并记录所有寄存器和程序计数器(PC) 数据.为了记录由给定二进制文件操作的所有数据, 使用GDB (GNU 项目调试器) 作为汇编级调试器.为了识别所有潜在的泄漏, 记录过程应尽可能详尽.针对每次加密操作, 每次汇编指令改变, 程序计数器(PC) 将会记录下一条指令的地址, 此时仿真能量迹所有的内部数据(如PC、寄存器等) 并记录, 生成日志文件以供后续分析使用.例如,在X86 架构64 位处理器执行的情况下, 系统授权可访问的内部数据如表2 所示.

表2 X86_64 架构可被合法访问的数据列表Table 2 Registers of X86_64 architecture that can be accessed legally

步骤五: 变换不同输入, 重复步骤三、步骤四.针对N次加密, 可重复步骤三、步骤四N次, 生成包含N项日志文件的数据库, 每项日志包含程序执行中所有信息, 包含原始代码及对应行、汇编代码及对应行、寄存器状态数据及指令地址(程序计数器), 作为后续解析生成仿真数据及逆向代码定位的依据.

步骤六: 解析调试信息并生成仿真数据.对步骤三、四生成的调试文件进行解析, 利用语义分析对汇编级代码进行验证.针对的值泄漏模型, 分析汇编程序中每条指令的目标寄存器内容的表达式, 进行正则匹配提取出寄存器存储的数值信息, 并提取当前指令地址作为后续预处理和逆向代码定位的依据.对每次加密, 能够根据其对应的调试日志文件生成一条仿真能量迹, 该仿真能量迹包含同一时刻(根据指令地址)所有寄存器的64 位比特信息.如对步骤五生成的N项日志文件进行解析, 则可生成N次加密对应的N条能量迹仿真数据, 生成数据集, 用于后续侧信道分析与评估.

如图4 所示, 以X86 累加器寄存器rax (在算术操作中用于存储结果和函数返回值) 为例, 为仿真能量迹AES-128 C 程序执行过程中rax 寄存器在AES 加密第一轮中的状态值变化情况.

图4 X86 平台下AES-128 Stagegate #1 C 代码实现仿真能量迹rax 寄存器生成的一条仿真能量迹Figure 4 A simulated trace acquired from AES-128 Stagegate #1 under X86 architecture

从图中可以清晰地看到在AES 计算第一轮时的四个函数, 如字节替代、行移位、列混淆、轮密钥加等操作, 以及一个密钥编排计算函数, 执行下一轮子密钥的计算.从图中可以发现, 使用该仿真方法生成能量迹具有实际的可操作性, 能够避免因物理采集的限制和实际操作人员的经验导致的实际侧信道信息测量困难耗时等不利因素, 更有利于探究代码本身的抗侧信道攻击能力.

3 仿真能量迹的对齐预处理

为了减少数据在时间上的偏移和冗余数据对后续分析速度的影响, 有必要进一步对仿真数据集进行对齐预处理.

由于程序执行过程中条件分支的影响, 不同输出可能导致程序执行出现不同的路径, 进而在汇编代码级别上执行不同数量的汇编指令, 从而导致程序在时间维度的执行出现不对齐不同步的现象, 并进一步可能出现影响安全性的时间隐通道, 进而攻击者通过计时攻击可能恢复出敏感数据.因此, 有必要对仿真数据进行对齐预处理, 一是为了后续在垂直振幅方向上进行泄漏检测和侧信道分析尝试恢复密钥, 二是可能检测出隐藏的时间隐通道进而对代码进行常数时间执行的修改.

传统的能量迹对齐根据分析能量迹泄漏值在时域和频域的分布来实现, 由于在本文中, 所提的基于仿真的C 代码级侧信道泄漏能量迹采集技术能够在集采寄存器数据的同时使用PC 记录当前指令的地址,所以无需使用传统对齐方法.使用程序计数器(PC) 以重新同步对齐数据泄漏的仿真能量迹.其基本原理是, PC 存放下一条指令所在单元的地址, 程序运行时完成第一条指令的执行, 而后根据PC 取出第二条指令的地址, 如此循环, 执行每一条指令.当执行一条指令时, 首先需要根据PC 中存放的指令地址, 将指令由内存取到指令寄存器中, 此过程称为“取指令”.与此同时, PC 中的地址或自动加1 或由转移指针给出下一条指令的地址.当变换程序输入, 再次执行程序运行到某处指令时, 相同的PC 意味着相同的汇编指令, 也即相同的操作.所以可以根据PC 作为程序执行流的标签, 对PC 进行同步, 即代表对程序执行流的同步.反应在仿真数据上, 即对仿真数据在垂直时间方向上的对齐, 消除由于分支执行导致的在相同的时刻两次执行运算数值的不一致.

举例说明, 在程序中引起能量迹数据不对齐的代码可能出现在以if (condition){···}else{···}为结构的条件分支中, 如在AES-128 代码实现列混淆操作时, 可能会出现如图5 条件判断代码.

图5 Stagegate #1 AES-128 实现中条件分支代码示例Figure 5 Sample code of condition branch in source code of Stagegate #1 AES-128

该部分代码为MixColumn 函数调用的子函数xtime, 该部分条件判断代码if (x& 0x80) 在汇编代码层级将编译产生汇编指令jns, 表示条件跳转指令, 程序将根据MSB(x)=0 判断是否跳转, 从而后续汇编指令运行条数不一致, 导致该部分寄存器数据产生时间上的不同步, 整体能量迹出现不对齐现象.另一方面, 该条件分支也可能因为非恒定时间执行产生时间隐通道泄漏.

当应用基于仿真的C 代码级侧信道泄漏能量迹采集技术重复采集多条仿真数据时, 可能会由于程序中条件分支的影响出现不同仿真数据峰值不对齐, 特别是随着样本点不对齐的叠加, 在能量迹后段不对齐现象将累加而更加明显.如图6 所示, 采集十条能量迹数据在图中灰色线条显示, 并计算其均值和方差, 如图6 中蓝色线条和黄色线条显示.可以发现, 在字节替代部分, 能量迹在时间上完美对齐, 均值和方差曲线的峰值与能量迹曲线峰值重合; 而在后段列混淆部分, 能量迹峰值不重合, 均值和方差均值不重合, 说明此处存在能量迹不对齐现象, 需要对齐处理进行校正.只有当所有数据集的PC 序列都相同时, 能量迹才能正确地同步对齐.

图6 十条仿真能量迹及均值方差Figure 6 Ten sample traces, average trace and variance trace

由于程序计数器PC 地址唯一确定仿真功耗的时间信息, 所以根据PC 地址确定对齐信息不难实现.为了减少时间不同步对仿真能量迹不对齐的影响, 可以根据数据集中PC 出现的频数判断是否出现条件分支, 进而对多余分支进行剪裁去除.

根据以上对齐算法思路, 可以完全消除由于时间因素引起的数据不对齐, 从而便于后续的密钥恢复分析.这里, 同样以X86 平台下AES-128 C 代码实现为例, 见图7, 经过对齐预处理后, 可以发现, 在列混淆部分数据尖峰不再分散, 能量迹均值和方差在能量迹后半段不再出现纵向衰减和横向扩散.

图7 十条仿真能量迹及均值方差(经过对齐)Figure 7 Ten sample traces, average trace and variance trace (trace synchronized)

4 基于信息相关性的代码级侧信道仿真分析

相关能量分析(CPA) 是计算曲线集合与预测值的皮尔逊相关系数.相关系数的值为−1 到1, 与1越接近说明相关性越大, 密钥猜测的正确性也越高.如果选择的泄漏模型与实际设备能耗相吻合, 相关性系数就为1.

图8 展示了对上节对齐预处理前后X86 平台下AES-128 C 代码实现rax 寄存器的100 条仿真能量迹进行相关分析得到的相关系数曲线.

图8 100 条仿真能量迹的CPA 攻击结果Figure 8 Result of CPA against 100 traces

未对齐前, 因为列混淆xtime 中if 语句的存在带来的时间差异, 列混淆处的泄漏被水平分散, 正确密钥的相关性峰值仅为0.5 左右, 与错误密钥的灰色曲线相关性峰值差别不大; 采用对齐预处理后, 正确密钥的相关性峰值为1.0, 与错误密钥的灰色曲线相关性峰值差别巨大.由此可见, 可以用相关性判断仿真能量迹的对齐效果.

5 泄漏点源代码反向溯源

通过前期的仿真能量迹采集, 能够在记录存储寄存器信息时同步记录当前指令的地址、对应的汇编代码以及源代码, 从而能够实现仿真数据-指令-代码的精确映射.对于生成的仿真能量迹数据集, 通过侧信道分析和评估技术, 能够检测侧信道泄漏量的大小并尝试攻击恢复密钥, 在数据端定位泄漏所在样本点, 从而反向映射找到泄漏所在指令, 进而映射至源代码存在泄漏风险所在代码片段.

例如, mov 和movzbl 指令在列混淆MixColumn 操作中被经常使用, 其将数据由一个寄存器拷贝至另一个寄存器, 在此过程中就有可能发生侧信道信息泄漏.通过在仿真能量迹中检测并定位发生泄漏的PC, 就能够反推至源代码片段, 从而给出该代码片段存在侧信道泄漏风险的提示.

通过不断改进迭代, 重复仿真-预处理-分析-漏洞定位流程, 直到确认在代码开发流程中对代码进行了相应的抗侧信道攻击防护, 能够提高侧信道评估的速度, 降低其实施难度, 整体流程如图9 所示.

图9 代码侧信道漏洞逆向定位及改进流程Figure 9 Work flow of vulnerable code location in code level side channel simulation

6 实验与分析

本文所选取的AES 实现为CHES 2016 CTF 白盒密码竞赛中的AES-128 样例实现Stagegate#1[9],本机处理器为Intel(R)Core(TM)i5-7300HQ CPU@2.50 GHz,内存为16 GB,操作系统为64 位Ubuntu 18.04, gcc 编译器版本为7.5.0, QEMU 仿真器版本为2.11.1, gdb-multiarch 调试器版本为8.1.1, 使用Python v3.9.1 处理和分析数据.实验目的是探究该实现在不同架构下的代码级侧信道仿真是否有差异性.

详细实验设置如表3 所示, 实验原理具体可参见第2、3、4 节.实验分为5 组, 分别对X86、ARM、MIPS、PowerPC、SPARC 等5 种主流处理器架构下的代码级侧信道软件仿真进行实验验证, 选取处理器位数为32 位或64 位.由于QEMU 仿真器利用动态代码翻译机制来执行不同于主机架构的代码, 所以能够在宿主X86 处理器上运行交叉编译的目标处理器架构代码.为了排除gcc 编译器优化(循环优化、分支优化、寄存器分配等) 的影响, 这里统一使用默认gcc 优化选项O0, 即不进行优化.

表3 多种处理器架构下的代码级侧信道软件仿真设置Table 3 Experiment setups of code level side channel analysis under multiple architectures

每项实验均采集100 条数据作为仿真能量迹, 均采集自AES 算法第一轮起始位置, 详细实验数据见表4.由表中可以发现, 在不同的处理器架构上, 所需要采集的采样点个数(即指令数) 和所需采集的寄存器个数存在差别, 但是对整个仿真的总时间没有显著影响.在所有实验中, 均可在单进程下在30 分钟以内完成整个仿真数据的采集, 由于实验一无需跨平台仿真处理器, 故在7 分钟以内即可完成仿真数据的采集.值得一提的是, 由于该仿真方法不依赖于物理算法实现, 理论上可以通过多进程方式对采集速度进行线性提速.在本机Intel(R) Core(TM) i5-7300HQ CPU @ 2.50 GHz 处理器下, 最多可以同时运行3 个进程从而实现3 倍的仿真提速.

表4 多种处理器架构下的代码级侧信道软件仿真实验结果Table 4 Results of code-level side channel software simulation for multiple processor architectures

经过上述五项实验, 可得到五组数据用于后续的侧信道分析.首先, 使用正则匹配等方法从日志数据中提取寄存器数据, 并存储为适合后续分析的能量迹数据格式.然后, 按照第4 节介绍的对齐方法, 按照PC 程序计数器所存储的地址, 对每条数据中出现条件分支的指令进行剪裁, 从而实现仿真数据能够完全按照相应汇编指令进行对齐.

本文使用经典的相关性分析(CPA)对仿真数据进行攻击,由于仿真数据不含噪声,故无需套用汉明重量等功耗模型, 可直接计算假设密钥的S 盒输出与仿真功耗的相关性.对每个处理器架构下的仿真数据,可分别对每个寄存器下的仿真能量迹进行CPA 攻击.通过对X86、ARM、MIPS、PowerPC、SPARC等五种处理器架构的23、19、40、39、41 个寄存器仿真数据进行攻击, 发现只有2–3 个通用寄存器存在信息泄漏情况, 如X86 架构的rax (累加器)/rcx (计数器)/rdx (数据器)、ARM 架构的r1/r2/r3 (通用寄存器, 用于子程序间传递参数)、MIPS 架构的v0/v1 (函数调用返回值存放寄存器)、PowerPC 架构的r8/r9/r10 (通用寄存器, 函数或系统调用开始的参数)、SPARC 架构的g1/g2/g3 (全局寄存器) 等, 可以发现, 存在泄漏的寄存器一般进行函数返回调用等功能, 将会泄漏代码运行中的敏感中间值, 具体统计结果可见表5, 其中下划线代表该寄存器泄漏全部密钥字节.

表5 Stagegate #1 AES-128 实现在不同架构处理器下的寄存器泄漏情况Table 5 Registers with leakages of different registers with Stagegate #1 AES-128 C implementation

下面更进一步地对泄漏点代码进行溯源.附录中详细展示了对5 种架构处理器泄漏寄存器仿真功耗的CPA 攻击结果, 可以发现, 正确密钥所对应的相关性曲线能够达到1 的相关性, 说明仿真功耗不存在噪声干扰, 直接泄漏敏感信息原值.因为在仿真寄存器功耗的同时记录下了程序计数器PC 的值, 故能量迹曲线的每个点都能够找到对应的PC 指令, 进而精确反向溯源至泄漏点对应的汇编代码和C 源代码.

通过对存在泄漏的X86 (rax/rcx/rdx)、ARM (r1/r2/r3)、MIPS (v0/v1)、PowerPC (r8/r9/r10)、SPARC (g1/g2/g3) 寄存器仿真能量迹进行CPA 攻击, 确定仿真能量迹上存在泄漏的特征点以及对应的汇编代码和C 源代码, 详细结果可参见附录.通过实验分析得出, 同样的AES 加密算法C 代码实验, 在不同的处理器架构下, 是存在泄漏的相似性和差异性的.为了便于后续分析, 根据附录图10–14 中泄漏情况, 将各架构处理器下的寄存器泄漏特性划分为三型, 分别为:

(1) I 型寄存器泄漏包括X86_rcx、ARM_r1、MIPS_v1、PowerPC_r8、SPARC_g3, 主要以sub-Bytes 函数mov/movslq 等汇编指令的寄存器拷贝泄漏为主;

(2) II 型寄存器泄漏包括X86_rax、ARM_r2、MIPS_v1、PowerPC_r10、SPARC_g2, 主要以mixColumns 函数mov/movzbl 等汇编指令的寄存器拷贝泄漏为主;

(3) III 型寄存器泄漏包括X86_rdx、ARM_r3、MIPS_v0、PowerPC_r9、SPARC_g1, 主要以mixColumns 函数mov/xor 汇编指令的寄存器拷贝和异或操作泄漏为主.

在本实验中, 通过对附录图中CPA 攻击的泄漏点位置和源代码溯源, 可以总结出该密码实现在不同架构处理器下的寄存器泄漏特性, 如表6 所示.在相似性方面, 实验中的5 种处理器架构均因Stagegate#1 AES-128 软件实现没有添加掩码和隐藏等防护措施, 在subBytes 和mixColumns 等位置能够通过假设密钥、猜测S 盒输出值、相关性攻击而恢复出原始密钥, 在泄漏点分布上呈现类似特征.在差异性方面,首先复杂指令集和精简指令集的处理器泄漏差异性较大, 如在II 型寄存器泄漏和III 型寄存器泄漏上, 通过实验发现在该类寄存器上X86 架构的rax 和rcx 寄存器泄漏情况与其他架构明显不同; 然后, 精简指令集的处理器泄漏差异性存在但不高, 如SPARC 架构的g3 寄存器上第16 密钥字节xtime 函数不存在泄漏, MIPS 架构的v1 寄存器subBytes、shiftRows、mixColumns、xtime 函数均存在泄漏, 融合了I 型寄存器泄漏和II 型寄存器泄漏的特征等.

表6 Stagegate #1 AES-128 实现在不同架构处理器下的寄存器泄漏特性Table 6 Register leakage features of different registers with Stagegate #1 AES-128 C implementation

7 总结与展望

本文对多种主流处理器架构下的代码级侧信道仿真特性进行了研究, 通过交叉编译和处理器虚拟化技术对AES-128 开源实现进行了跨平台寄存器仿真功耗采集和侧信道分析, 验证该技术通用性和探究主流处理器架构下仿真功耗泄漏的相似点和差异性.通过一些对比实验, 可以发现: (1) 代码级侧信道仿真能够反应源代码实现层面的安全性; (2) 代码级侧信道仿真能够验证多种架构处理器的密码实现代码安全性;(3) 多种架构处理器的寄存器泄漏情况大致相同, 但也因指令集和架构特性呈现差异化特征.

通过代码级侧信道仿真, 能够实现跨处理器平台的源代码层面侧信道分析, 发现可能存在泄漏的寄存器, 检测源代码的实现安全性.下一步, 考虑在已有基础上, 对出现泄漏的源代码进行安全防护, 实现检测和防护的闭环.此外, 针对公钥密码的代码级侧信道仿真也值得进一步研究.