运行时代码多态性防御侧信道攻击

运行时代码多态性作为对抗侧信道攻击的保护机制

1 引言

侧信道攻击是一种通过观察与安全计算活动相关的物理现象来恢复密钥的有效手段。根据对被攻击程序的了解（例如高级加密标准密码算法），攻击者将尝试在观测轨迹与关于秘密计算过程中使用的中间值的假设（例如第一个s盒计算的输出）之间建立相关性。提供最佳相关值的假设随后被用于恢复密钥（例如高级加密标准密钥的值）。通常，观测轨迹中的少数几个点会与假设呈现出良好的相关值，这些点对应于泄漏点，即在计算过程中密钥信息可被观测到的时间点。

针对侧信道攻击，有两种主要的防护方案是有效的：隐藏和掩码。掩码的核心思想是将安全计算中的敏感值拆分为多个份额，以打破观测值与假设中间值之间的相关性。要从掩码实现中恢复密钥，并且在各份额在不同时间计算的前提下，攻击者需要进行高阶相关性分析，即同时涉及多个观测点的分析。然而，高阶攻击的计算复杂度随攻击阶数呈指数级增长，因此在实际中更难实施。

隐藏则是通过在时间上（在安全计算期间）和空间上（芯片上的操作位置）移动信息泄漏点，并减小可观测泄漏的幅度来实现防护。实际上，侧信道相关性分析依赖于对目标精确的空间和时间控制，而攻击的有效性与观测信号中空间和时间变化的程度密切相关[13]。将泄漏点在多个执行过程中分散到不同的时间和位置，将显著降低攻击的有效性，从而需要更多的观测轨迹和/或更强大的分析手段才能恢复密钥。在实践中，抗侧信道攻击的鲁棒性通常通过结合使用隐藏和掩码这两种防御措施来实现。

我们将多态性定义为在运行时定期改变安全组件的行为而不改变其功能属性的能力。通过修改被攻击目标观测的时间和空间属性，多态性增加了在侧信道攻击中进行相关性分析的难度。因此，它可以被视为一种隐藏型防御措施。

非确定性处理器[15]实现了我们所说的多态执行，即从存储在程序内存中的静态二进制输入中进行指令混排的执行。May等人实现了动态指令混排[15]和随机寄存器重命名[14]。Bayrak等人[6]描述了一种指令混排器：一种插入在处理器和程序内存（指令缓存）之间的专用IP。如今，许多安全元件集成了类似的功能，以去同步化观测轨迹并降低信噪比。专用硬件设计在提高安全性的同时具有更好的性能，但成本更高。随着物联网市场的快速增长，纯软件解决方案更具吸引力，因为它们可以更容易地适应现有的各种产品架构，并且具备可升级性。

仅通过软件手段，[1,10]提出编译一个包含多个功能等效执行路径的程序，其中在运行时随机选择一条执行路径。这种方法以增加程序大小为代价，减少了执行时间上的开销。据我们所知，Amarilli等人[3]是首次利用代码变体编译来抵御侧信道攻击的研究者。借助修改后的静态编译器，在每次执行前生成一个新的程序版本，以在运行时对指令和基本块进行混洗。他们的方法被证明可使AES上的差分功率分析的迹数量增加20倍。Agosta等人[2]的工作是与我们的工作最接近的。他们提出了一个代码变形运行时框架，该框架涉及寄存器重命名、指令混洗以及生成语义等价的代码片段。

本文中，多态性通过由随机数据驱动的运行时代码生成来实现。其核心思想是在目标设备上定期生成受保护二进制代码的新版本。每个程序版本在功能上是等效的，但其实现方式不同，因此每次执行都会导致不同的观察结果。该多态代码生成器由一个适用于嵌入式系统约束的运行时代码生成框架生成（第2节）。我们详细介绍了通过选择随机寄存器、随机选取语义等效指令、重排序指令以及插入噪声指令来为生成代码引入变异性的机制。我们对所提出方法在AES软件实现上抵御相关功耗分析（CPA）的有效性进行了实验评估，并表明执行时间和代码大小开销与资源受限嵌入式目标的内存和计算能力相兼容（第3节）。我们在第4节介绍相关工作，并在第5节总结。

2 面向嵌入式系统的运行时代码多态性

2.1 deGoal 概述

deGoal 是一个用于运行时代码生成的框架。其最初的动机是利用运行时代码特化来提升程序性能，例如执行时间、能耗或内存占用。在本节中，我们首先概述 deGoal 的特性，然后介绍我们如何将其扩展以用于安全性目的。

在用于运行时代码生成的经典框架（如解释器和动态编译器）中，目标是提供一个受编程语言语法和语义定义约束的通用基础设施。这类解决方案的通用性带来了较高的运行时代码生成开销，体现在内存占用、计算时间和计算能耗方面。在deGoal中，采用了不同的方法：代码段（后文称为内核）由专用运行时代码生成器（称为编译单元）在运行时生成并调优。每个编译单元专门用于生成一个内核的机器代码。语法和语义分析在静态编译时完成，而编译单元仅嵌入所选运行时优化所需的处理知识。因此，编译单元提供了极快的代码生成速度（比典型的运行时代码解释或动态编译框架快10到100倍），具有较低的内存占用，可在小型微控制器架构（如8/16位微控制器）[5],上运行，并且可移植[8]。

构建和执行使用deGoal的应用程序包含以下步骤，如图1所示：编写源代码，结合使用C源代码和我们专用的cdg语言；编译应用程序的二进制代码和编译单元的二进制代码；在运行时，通过编译单元生成内核的二进制代码，最后运行这些内核。

Cdg是一种类汇编的领域特定语言。从程序员的角度来看，它代表了一种主要的范式转变：Cdg表达式描述的是将在运行时生成的机器代码，而非待执行的指令。编译单元通过结合ANSIC和Cdg表达式来实现。C语言用于描述编译单元的控制部分，该部分将驱动代码生成，而Cdg表达式则执行代码生成。

Cdg指令集包含一个变长寄存器集，可由程序员进行扩展。基于这一高级指令集，编译单元会根据以下因素将Cdg表达式映射为机器代码：（1）待处理数据的特性，（2）代码生成时的执行环境特性，（3）目标处理器的硬件能力，（4）执行时间和/或能耗性能指标。在所有情况下，代码生成速度快、生成的代码高效，并且适用于微控制器等低资源嵌入式系统[5]。

2.2 一个多态SubBytes函数

本节通过高级加密标准的SubBytes函数实现作为deGoal的教程介绍deGoal，随后详细介绍运行时代码生成的内部机制。这也是我们在实验中使用的受保护的实现（第3节）。

代码生成器使用Cdg实现，如同任何其他在deGoal中设计的代码生成器一样。在此阶段，多态代码生成是代码生成框架提供的一项功能，但无需由程序员显式控制。在清单1.1中，函数gensubBytes是一个标准的C函数，其实现是在静态编译之前从Cdg翻译为纯C源代码。

void gen_subBytes ( cdg_insn_t * code ,
uint8_t * sbox_addr , uint8_t * state_addr )
{
#[
开始代码 前奏 
类型 uint32 int 32 
分配 uint32 状态 , s盒 , i , x , y 
移动 状态 , #( state_addr ) 
移动 s盒 , #( sbox_addr ) 
移动 i , #(0) 
循环 : 
加载字节 x, @( 状态 +i) // x :=状态 [i] 
加载字节 y, @( s盒 +x) // y := s盒 [
x] 
存储字节 @( 状态+i), y // 状态 [i]:=y 
加 i , i , #(1) 
不等则跳转 循环 , i , #
(16) 
返回 
结束
]#;
}

deGoal 允许在 #[ 和 ]# 分隔符之间混合用于代码生成的 Cdg 表达式和 C 代码。此外，C 表达式可以插入到用 #( ) 括起来的 Cdg 表达式中；它们将在代码生成时（即执行编译单元时）被求值。SubBytes 子程序的程序代码写入变量 code 所包含地址的内存缓冲区中（第 1 行和第 5 行）。第 6–7 行声明了类型化变量的实例化，这些变量将在运行时代码生成期间映射到物理寄存器。

变量 state 和 sbox 分别存储 AES 状态的地址和 S 盒的地址（C 变量 state addr 和 sbox addr 第 2 行）。一个标签（loop，第 11 行）定义了对 16 个状态字节循环的起始位置。变量 i 存储循环索引，它在第 10 行初始化，并作为加载和存储指令的偏移值使用（分别在第 12 行和第 14 行），其中 @(a+k) 的表示法（第 12 至 14 行）表示对存储在变量 a 中的地址进行间接内存访问，并由地址变量 k 做偏移。S 盒替换在第 14 行完成，其中临时变量 y 被加载为地址 sbox 偏移 x 处的内存内容。Cdg 指令 rtn（第 17 行）生成 SubBytes 子程序的终止代码，而 Cdg 指令 End（第 18 行）终止代码生成：它清空指令调度器中剩余的活动指令（第 2.3 节），并发出向后分支的机器代码，这些分支的目标地址无法在第一次代码生成遍历时计算得出（本文未详细说明）。

2.3 使用deGoal实现代码多态性

在本研究中，我们重新调整了deGoal的原始目标，以专注于安全性方面：我们利用 deGoal 在运行时代码中的灵活性，通过生成实现运行时代码多态性。由多态代码生成器生成的程序代码此后称为多态实例。

寄存器分配。 在动态编译器中，指令选择和指令调度通常在寄存器分配之前执行[12]。尽管动态编译器中使用的分配技术（如线性扫描）[17],与静态编译器中常用的图着色相比具有较低的计算开销，但它们仍然超出了我们目标平台可用计算能力的范围。因此，在一个编译单元中，寄存器分配首先通过贪心算法（算法 1）在指令调度之前完成。我们的目的是减轻指令选择和指令调度的压力：如果先进行寄存器分配，则可以从更简单的中间表示进行指令调度：我们的分配器只需维护一个可用空闲寄存器的列表即可。

算法1. 随机寄存器分配

输入：可用寄存器列表 free
输出：更新后的可用寄存器列表 free
输出：分配的物理寄存器的ID reg
从可用寄存器列表中随机获取一个寄存器
l ← Length(free)
i ← Rand(0, l − 1)
reg ← free[i]
从空闲寄存器列表中移除寄存器
ifree ← Delete(free, i)

Instruction Selection. 指令选择在寄存器分配之后进行，原因如前所述。指令选择在Cdg表达式级别上执行：根据目标处理器架构和代码生成选项（例如，倾向于代码紧凑性或代码执行时间），每个表达式可以映射到一个或多个机器指令。指令选择通过由随机值驱动的switch … case段来实现。为了实现代码多态性，我们引入了额外的变体，以提供更多的多态性机会。本文实验中使用的、可能由指令选择所选用的语义等价形式如下所述（r表示一个随机值）：

• c := a xor b <=> c :=((a xor r) xor b) xor r
• c := a xor b <=> c :=(a or b) xor (a and b)
• c := a ‐ b <=> k := 1; c:=(a + k)+(not b)
• c := a ‐ b <=> c :=((a + r) ‐ b) ‐ r

我们强调，尽管在当前实验中为随机指令选择引入的语义变体数量较少，但添加新的指令变体只会对嵌入到目标上的代码生成库的内存占用产生影响，而不会影响代码生成的执行时间。换句话说，增加选择变体将增大指令选择中使用的 switch … case段的大小，但不会影响从switch表达式分支到其中一个case的性能。

指令调度。 上述的指令选择过程会在一个有界有序指令缓冲区中生成指令，该缓冲区的行为类似于先进先出队列。在此阶段，指令缓冲区包含机器指令编码以及对defs和uses寄存器（即被修改和被读取的寄存器）的描述。该指令缓冲区采用双向链表实现。这显然会增加数据结构的操作开销，但我们选择这种实现方式是为了最大化插入机会，而非执行效率。实验部分表明，多态代码生成的性能仍然良好。

在传统编译器中，指令调度旨在提高代码执行的性能：通过在程序内存中对机器指令进行排序，以最小化执行时间，特别是处理器空闲周期的数量。调度的难点在于，在不破坏原始源程序语义的前提下，找到机器指令的可能最优排序。为实现这一点，需要考虑资源约束、控制依赖和数据依赖。

在代码多态性的情况下，我们的目标是利用调度机会生成同一源程序的多个变体，所有变体均功能等价且语义正确。因此，代码性能只是次要考虑因素，我们主要关注影响代码正确性的资源约束，而不是那些仅影响程序性能的。指令调度通过一次遍历完成（算法2）：每次将新指令插入指令缓冲区时，首先通过比较该插入指令与缓冲区中已存储指令的定义与使用，计算出可能的插入槽位列表。接着，在先前确定的插入槽位列表中随机选择一个插入位置。如果未找到任何插入槽位，则将新指令追加到指令缓冲区的末尾。如果指令缓冲区已满，则将其第一个指令发射到程序内存中，以释放一个指令槽位。

流水线冲突[16],仅影响程序性能而不影响程序正确性，在我们的调度策略中未予考虑。我们的主要目的是降低调度的计算开销，但这一选择还带来了另一个有趣的效果：处理器停顿——作为流水线冲突在程序执行过程中的一种可观测效应——可能会在程序执行的观察中增加额外的时间变化来源。为了实现快速代码生成，控制依赖约束通过将控制指令视为调度屏障来简单处理：当遇到控制指令时，清空指令缓冲区。

插入噪声指令。 在插入新指令之前（第2.3节），噪声指令被追加到指令缓冲区的结束位置。n噪声指令以概率 p插入，其中 n服从可配置的均匀离散分布[1； N]。如有需要，将从空闲寄存器列表中随机选择额外寄存器。若无可用寄存器，则随机选择寄存器，并在其使用前后将其压入和弹出堆栈。可插入多种类型的指令：在单个处理器周期内执行的核心算术指令（例如整数运算加或sub），或在多个处理器周期内执行的指令（例如在ARM Cortex‐M内核上执行的乘加运算mla），以及对用户可能提供的数据表的内存访问（例如s盒查找表）。

代码生成间隔。 它与相对于执行次数的新的多态实例的生成频率相关（公式1）。ω是一个无单位的值，位于[1；+∞[。当 ω= 1时，在每次执行前都会生成一个新的多态实例；如果 ω →+∞，则仅在启动时生成一次多态实例，这等同于使用静态生成的代码。我们的假设是， ω越接近1，物理攻击就越困难，因为两次执行的观测结果具有相关性的概率更低。另一方面，代码生成所带来的开销随着 ω的减小而增大。

$$
\omega = \frac{\text{nb. executions}}{\text{nb. code generations}} \quad (1)
$$

3 实验评估

3.1 实验设置

我们使用了意法半导体（STMicroelectronics）的STM32VLDISCOVERY评估套件。该开发板配备了一个运行频率为24兆赫兹的Cortex‐M3内核，仅提供128千字节的闪存和8千字节的内存，并且未配备硬件安全保护。所有二进制程序均使用Code Sourcery提供的arm‐none‐eabi GNU/gcc工具链（版本 4.8.1）生成，编译选项为‐O3 ‐static ‐mthumb ‐mcpu=cortex‐m3。因此，我们将我们的实现与目标编译器所能获得的最快的参考实现进行了比较。

侧信道迹是使用2208A PicoScope获取的，该设备具有200兆赫兹带宽和8位垂直分辨率。我们使用Langer的电磁探头RF‐B 3‐2和Langer的PA 303前置放大器。采样以500兆样本每秒的速率在10000个样本的窗口内进行。

我们的参考实现是一个遵循NIST规范的无保护的8位AES实现，所有轮函数均由针对该AES实现定制的多态代码生成器在运行时于内存中生成，如第2节所述。上述所有多态机制均在代码生成器中启用。插入噪声指令的概率设为 p= 1/8，插入的指令数量从均匀离散分布[1； 8]中选取。每执行 ω={1, 10, 100, 1000, 10000}次AES后可生成一个新的多态实例，但在侧信道攻击实验中，我们采用最短的代码生成间隔 ω= 1。

3.2 攻击模型

我们在第一轮AES的SubBytes函数输出上执行攻击。与大多数将同步点设置在AES加密开始处的一阶CPA分析不同，我们考虑的是攻击者能够在SubBytes函数开始时创建一个同步点的情况。为了便于测量迹的时间对齐，在板子上的GPIO引脚上生成一个触发信号，在SubBytes函数执行期间保持高电平。使用这种设置进行安全性评估时条件更为严格，因为多态AddRoundKey函数的执行变异性不会对观测轨迹的变化产生影响。

代码生成器本身也可能成为攻击的目标，即使它无法访问密钥的值。然而，此类攻击超出了本文的范围，留待未来工作研究。

3.3 相关性功耗分析

我们对无保护版本和受保护的实现都进行了首次阶数CPA。我们使用汉明重量来建模电磁辐射第一个SubBytes函数输出的一个字节。该分析针对每个可能的密钥部分假设值，计算每条轨迹与模型之间的皮尔逊相关系数 ρ的样本估计值 r。

图2展示了对无保护实现进行CPA攻击的结果。在相关值高于0.8的情况下，仅需35条迹即可将正确密钥与其他所有密钥假设区分开来。该结果验证了实验设置以及相关性分析中所采用的汉明重量模型的合理性。作为多态性影响的一个示例说明，我们在图3中展示了针对我们的多态实现进行CPA攻击的结果，其代码生成间隔为 ω= 200，即远高于从无保护实现中恢复AES密钥所需的迹数量。在此情况下，前200条迹来自同一个AES多态实例的执行，因此正确密钥假设的相关值明显区别于其他密钥假设。在200次执行后，生成并执行一个新的多态实例，用于接下来的200次执行。多态性对相关迹的影响显而易见：在200条迹之后，正确密钥假设的相关性突然下降。在300条迹之后，正确密钥假设不再能与其他密钥假设区分开来，因为相关性分析混合了两个行为不同的AES实例的执行迹。这也说明了在实际中，代码生成间隔 ω的取值必须严格小于从无保护实现中恢复密钥所需的迹数量。然而，这一设置在很大程度上取决于目标的性质以及在无保护实现上实施攻击的可行性。

当每次执行后都生成一个新的多态实例时（ω= 1），需要100000条迹才能以50%的成功率恢复密钥（图4）。在120000条迹后，成功率达到了100%。

3.4 执行时间开销

为了估算我们的保护措施为参考实现带来的成本，我们测量了执行时间开销 k（公式2），其中 tref、 tgen和 tpoly分别表示参考的无保护实现的平均执行时间、多态运行时代码生成的平均执行时间和多态实例的平均执行时间。我们对执行时间开销的度量考虑了由于执行多态实例（其代码相较于参考的无保护实现为次优代码）以及由于运行时代码生成所导致的执行时间增加。在此测量中，我们认为代码生成带来的开销分布在 ω次运行中。

$$
k = \frac{t_{\text{gen}} + \omega \times t_{\text{poly}}}{\omega \times t_{\text{ref}}} \quad (2)
$$

表1比较了无保护的AES与多态AES的几个变体的执行时间。在本节中，我们将完全多态AES命名为我们的实现，其中所有轮函数均受到多态性保护。无保护版本的执行时间为5320个处理器周期。我们观察了多态版本在1024次运行中的执行时间。完全多态AES的执行时间为10487至13696个处理器周期（平均12211周期）。表1还说明了这样一个事实：如果仅有一个轮函数受到多态性保护（AddRoundKey 或 SubBytes），则执行时间开销会降低。由于实验目标微架构相对简单，无保护版本的执行时间在多次测量中完全稳定。然而，相比之下，多态版本的执行时间表现出显著的变异性。考虑到无保护版本执行时间的稳定性，这种变异性只能归因于每个多态实例中的实现差异。

	无保护版本			AddRoundKey			SubBytes			所有轮函数
	最小值	平均值	最大值	最小值	平均值	最大值	最小值	平均值	最大值	最小值
texe	5320	5320	5320	6340	10487	15565	10894	1205977	166	127269
tgen	0	0	0	0	0	0	0	0	0	0

表2列出了针对表1中详细描述的执行时间测量所计算出的开销 k，适用于不同的代码生成间隔 ω。对于完全多态AES，在每次AES执行前都生成新的多态实例（ω= 1）的情况下，我们测得平均开销为20.10（最坏情况为26.16）。然而，当代码生成间隔增加时，开销迅速下降，因为运行时代码生成的成本被分摊到了同一多态实例的多次执行上。考虑到从无保护的AES中恢复密钥所需的迹的数量，代码生成间隔为 ω= 10的情况可能成为一个可利用版本。在这种情况下，执行时间开销平均仅为4.36（最坏情况为4.85）。表2还说明了多态实例产生的成本仅。对于较大的代码生成间隔（例如 ω= 10000），运行时代码生成在总开销中的占比变得可以忽略不计，即开销仅代表执行多态实例的成本，相较于参考的无保护实现。

	AddRoundKey			SubBytes			所有轮函数
	最小值	平均值	最大值	最小值	平均值	最大值	最小值	平均值	最大值
ω= 1	3.16	4.91	6.37	5.81	7.27	8.94	20.10	22.94	26.16
ω= 10	1.32	1.50	1.66	1.59	1.76	1.92	3.86	4.36	4.85
ω= 100	1.09	1.16	1.22	1.16	1.21	1.25	2.17	2.50	2.78
ω= 1000	1.09	1.13	1.18	1.16	1.15	1.20	2.17	2.32	2.59
ω= 10000	1.05	1.12	1.18	1.11	1.15	1.19	1.99	2.30	2.58

实际上，多态实例的代码在执行时间方面效率较低，这是由于指令顺序的错乱、使用了次优（且更长）的代码序列以及执行了无用的指令所致。

3.5 内存占用

表3报告了我们工作的内存占用，包括代码生成器的大小以及为代码生成预留的内存大小。完整多态实现带来了16KB的程序大小开销，但可以通过对高级加密标准部分应用多态性来减少内存占用：如果仅轮密钥加和字节代换具有多态性，则内存开销仅为8KB。

	Text	数据	BSS	总计
无保护版本	6144	40	772	72948
仅AddRoundKey	8128	56	2948	10544
仅SubBytes	7540	56	3980	15032
轮密钥加+字节代换	10964	88	6028	23100
完全多态AES	16984	88

4 相关工作

Agosta等人[2]的工作与我们的研究最为接近：他们首次在一个运行时代码转换框架中整合了语义等价的代码序列、随机寄存器分配、指令混洗和数组排列，以实现对侧信道攻击的保护。这些代码变换应用于基于OpenSSL的32位高级加密标准实现中的64个异或指令。由于需要更多的迹的数量从无保护实现中提取密钥（11600）时，可利用的代码生成间隔较高（介于100到3000之间），高于我们的工作。多态代码实例和代码生成器的执行时间分别为 1.07×和 392.5×无保护的AES的执行时间，且报告了 5×的开销用于 ω= 100。在我们的工作中，所有高级加密标准程序的指令均受到多态性保护，平均开销仅为 2.50×，用于 ω= 100；在最坏情况下 ω= 1，代码生成是参考无保护的AES执行时间的 23.9×。

其他工作提出了多态程序的设计，无需运行时代码生成的介入，而是通过随机选择功能等价的执行路径实现。博莱等人[7]描述了针对侧信道逆向工程保护Java卡的方法。该方法适用于虚拟机中的解释器；它描述了解释器中功能等价代码的随机关联与选择。与我们的工作相比，该工作未使用随机寄存器分配以及代码段之间的指令混洗。类似地，克兰等人[10]提出在不同程序片段副本之间随机切换执行，以保护程序免受缓存侧信道攻击。这些片段变体由修改后的编译器在离线阶段生成，涉及插入空操作指令和随机内存访问。在程序执行期间，跳板通过基于表的随机间接分支动态选择这些片段。他们的实现在通用多核桌面计算机上运行。阿戈斯塔等人使用修改后的LLVM工具链编译器，目标为基于ARM Cortex‐M4的微控制器[1]。受保护程序部分的每条指令被替换为多个功能等价的指令序列。此外，对内存访问和寄存器溢出应用了掩码方案。他们报告称，对于与我们研究中相同的密码AES‐S，其性能开销为 11×，但代码大小开销为 9×。

执行噪声指令（也称为虚拟指令）是另一种通过引入随机时间延迟来缓解侧信道攻击的已知技术。在软件中，通过从预定义位置跳转到专用例程来实现虚拟指令的执行在程序中（例如，在要保护的代码部分之前、期间和之后）或通过触发随机延迟中断来实现。该例程例如执行一个循环，将随机初始化的寄存器[9]的值递减至零。隐马尔可夫模型[11]或模式匹配[18]是有效的技术，可用于从观测轨迹中移除对应于执行或虚拟指令的部分，或在轨迹中创建同步点，以消除由随机延迟引起的错位。然而，这些分析依赖于插入的时间噪声具有显著特征（例如中断处理程序的头部）。安布罗斯等人[4]提出随机插入一组有限的预定义指令，这些指令类似于常规代码指令，并且也可以使用随机选择的寄存器。他们认为，这类指令会修改处理器的内部状态，其性质与程序中的其他指令相同，因此由于寄存器中的位翻转而导致更大的功耗变化。我们工作的贡献之一是将这一思想进一步推进：插入程序中的噪声指令与真实程序指令（算术操作、内存操作等）性质相同，并可针对一个或多个随机选择的空闲寄存器。此外，得益于运行时代码生成，我们能够比现有的虚拟指令技术更有效地将噪声指令与程序其余部分交织在一起。

5 结论

我们提出了一种实现运行时代码多态性的框架，作为一种针对侧信道攻击的通用保护手段。我们的实现依赖于一个轻量级的运行时代码生成框架，适用于嵌入式系统，这类系统通常由于计算和内存资源有限，无法使用即时编译器等运行时代码生成工具。据我们所知，这是首次在如此有限的计算资源（8千字节的内存和128千字节的闪存）下实现多态性运行时代码生成，并且具有可接受的运行时开销。此外，我们的实现在密码系统中适用，也可用于其他需要防范物理攻击的软件组件（例如PIN码管理、引导加载程序等），并可广泛应用于多种计算平台[8]。

在我们的实验平台上，我们观察到在无保护的高级加密标准中，密钥可以在少于50条迹的情况下被恢复。然而，在许多实际平台中，即使是在无保护实现上，侧信道攻击也可能需要更多的迹才能成功提取密码密钥：通常超过10000或100000条迹。这意味着在实践中，可以有效地使用更大的代码生成间隔来实现多态性，从而使我们方法的开销变得更加可控。其他设计参数，例如控制插入噪声指令的参数，将对安全裕度以及执行时间和代码大小开销产生重要影响。

最后，我们强调多态性本身并不是目的per se，而应该与其他最先进的保护措施相结合（例如掩码）。鉴于我们方法的通用性和实现的轻量性，我们认为将其集成到更全面的安全方案中是切实可行的。