AES侧信道攻击

一、题目介绍

通过 USB 直接连接电脑,可以同时满足 badge 的供电和串口通信,因此我们调节 Badge 开发板侧边开关拨至 RF1 而非 SW1 以设置板子为 USB 供电而非电池供电,然后通过 USB 串口以 38400 波特率连接上开发板,会看到如下的题目信息(如果使用电池供电,则会提示电压不足,不会显示题目信息):

开发板关键信息介绍:

我们只关注 AES 侧信道攻击获取密钥这个实验。由题目和开发板介绍,可知是希望通过侧信道/故障注入的方式恢复 AES 密钥,通过串口发送 'AES',芯片会进行 AES 加密运算,AES 加密过程中 PB11 作为触发信号会先拉高再拉低。实验以电压故障注入为例,打在 AES 第九轮运算的位置,产生足够多的错误密文,从而通过 DFA 恢复密钥。最后输入正确的 flag 即可成功点亮 PB0。

二、逻辑接线图

这张图展示的是电压故障注入攻击的硬件接线方案,核心设备是左侧的 PowerShorter。

整体攻击流程: 电脑通过串口触发 AES → PB11 输出触发信号 → PowerShorter 在精确时刻短路 3.3V 电源 → MCU 计算出错 → 电脑读取错误密文 → 与正确密文配对用于 DFA 分析。

  • E1+(红线):连接目标板的 3.3V 电源线,用于在精确时刻将电源瞬间短路到地,制造电压毛刺,使 MCU 在执行 AES 运算时产生计算错误。
  • RELAY1(蓝线):连接目标板的 NRST(复位引脚),通过继电器控制目标板复位。当 glitch 导致芯片挂死时,可以远程重启,对应代码中的 restart() 函数。
  • GND(绿线):共地,保证信号参考电平一致。
  • E1-Tri(粉线):连接目标板的 PB11 引脚,这是 AES 加密的触发信号。目标板开始 AES 运算时拉高此引脚,PowerShorter 检测到后,经过设定的 glitch_delay 延迟,发出持续 glitch_pulse 宽度的短路脉冲。
  • 功耗采集(青色线):接示波器,用于观察功耗波形,辅助定位 AES 运算的精确时间窗口。
  • 串口(右侧):接电脑,用于发送 AES 指令(ser.write(b'AES\n'))并读取加密结果。

三、实物接线图

通过示波器以 PB11 为触发信号,采集功耗波形可以大致看出 AES 第九轮运算时间在触发后 2.3ms 左右:

四、编写故障注入代码

Python 复制代码
# 引入库
from power_shorter import *
import faultviz, time, random,serial
import numpy as np
from osrtoolkit.dfa import aes as dfaaes

# 初始化PowerShorter端口和串口端口
ps = PowerShorter('COM4')
ser = serial.Serial("COM19", 38400, timeout=0.5)

# 启动一个故障注入结果的实时可视化界面服务
faultviz.start_view_service(port=12345)
vt = faultviz.ViewWidget()

# 定义重启函数
def restart():
    ps.relay(RELAY.RELAY2,1)
    time.sleep(0.5)
    ps.relay(RELAY.RELAY2,0)
    time.sleep(0.5)

# 获取一次正常(无故障注入)的 AES 加密结果,作为后续 DFA 攻击的参考基准
ser.reset_input_buffer()
ser.write(b'AES\n')
c = ser.read(32)
c_correct = bytes.fromhex(c.decode())
c_correct

# 初始化一个空列表,用来收集所有满足 DFA 攻击条件的正确密文与故障密文配对
fault_list_pair = []

# 执行一次完整的电压毛刺故障注入尝试的函数
def STM32F303_attack():
    glitch_pulse = random.randint(14, 18)
    glitch_delay = random.randint(229500, 232500)
    ps.engine_cfg(Engine.E1, [(0, glitch_delay), (1, glitch_pulse), (0, 1)])
    ps.arm(Engine.E1)
    time.sleep(0.5)
    
    ser.reset_input_buffer()
    ser.write(b'AES\n')
    line = ser.read(32)
    
    try:
        c = bytes.fromhex(line.decode())
        s = ps.state(Engine.E1)
        if s == "glitched":
            if dfaaes.DfaAESSubFunctions.check_fault_pair(c_correct, c) == 9:
                status = "SUCCESS"
                fault_list_pair.append((c_correct.hex(), c.hex()))
            else:
                status = "NORMAL"
            vt.update(state = status, delay = glitch_delay, pulse = glitch_pulse, result = c.hex())
    except:
        restart()

# 无限循环地反复尝试故障注入,直到收集到足够多的有效故障对,实际上此实验只需20个左右的有效故障对
while(1):
    STM32F303_attack()
    
# 展示故障注入结果的实时可视化界面
vt.show()

# 用收集到的故障对反推 AES 密钥
DFA_KEY = dfaaes.DfaAES(fault_list_pair)
DFA_KEY.get_master_key()

为什么要在AES的第9轮进行故障

  • AES-128 共 10 轮,每轮依次执行 SubBytes、ShiftRows、MixColumns 和 AddRoundKey 四个操作,但最后一轮(第 10 轮)是个例外,它省略了 MixColumns。这个结构上的特殊性,正是第 9 轮成为最佳攻击点的根本原因。
  • 如果故障注入得太晚,比如在第 10 轮,由于这一轮没有 MixColumns,一个字节的故障在输出密文中也只影响一个字节。差异信息太少,无法提供足够的数学约束来求解密钥。反过来,如果注入得太早,比如在第 8 轮或更前面,故障会经过多轮 MixColumns 的反复扩散,一个字节的错误最终会蔓延到几乎全部 16 个字节,差异过于复杂,数学上也无法有效建立方程。
  • 第 9 轮恰好处于一个平衡点。在第 9 轮 SubBytes 之前注入一个单字节故障后,这个错误依次经过第 9 轮的 SubBytes 和 ShiftRows(仍然只有一个字节受影响),然后经过第 9 轮的 MixColumns,此时一个字节的错误被扩散到同一列的 4 个字节。之后进入第 10 轮,由于第 10 轮没有 MixColumns,这 4 个错误字节各自独立地经过 SubBytes、ShiftRows 和 AddRoundKey,不再进一步扩散。最终密文中恰好有 4 个字节与正确密文不同。
  • 4 个字节的差异之所以最理想,是因为通过对比正确密文和故障密文,可以精确定位哪 4 个字节受到了影响,而这 4 个字节直接对应最后一轮轮密钥中的 4 个字节。利用 SubBytes 的差分特性,每个差分方程能把一个密钥字节的候选值从 256 个缩小到大约 2 到 4 个。一组故障对约束 4 个密钥字节,多组故障对覆盖不同的列,通常只需要 2 到 3 组有效故障对就能唯一确定全部 16 个字节的最后一轮轮密钥,再通过密钥扩展的逆运算还原出原始主密钥。

判断每次故障是否为SUCCESS的依据

判断 SUCCESS 的依据:if dfaaes.DfaAESSubFunctions.check_fault_pair(c_correct, c) == 9

  • c_correct 是正确的 AES 加密输出(无故障注入时的密文);
  • c 是本次 glitch 攻击后获得的密文(可能已被注入故障);
  • check_fault_pair(c_correct, c) 函数的作用是对比正确密文和故障密文之间的差分模式,反推故障究竟发生在 AES 的哪一轮。不同轮次注入的故障在最终密文中会留下不同的差分特征:如果只有 1 个字节不同,说明故障发生在第 10 轮;如果有 4 个字节不同且符合特定的列结构,说明故障发生在第 9 轮;如果大量字节不同,说明故障发生在更早的轮次。函数通过分析这些差分的结构和位置关系,判断出故障对应的轮次编号,并将其作为返回值。只有当函数判定故障恰好发生在第 9 轮时,才认为这组故障对是有效的。

DFA代码解释

  • DFA_KEY = dfaaes.DfaAES(fault_list_pair):把之前循环中积攒的所有有效故障对(正确密文 + 故障密文的配对列表)传入 DFA 求解器,创建分析实例。
  • DFA_KEY.get_master_key():执行 DFA 数学运算,输出最终的 AES 主密钥。
  1. 每组故障对中,正确密文和故障密文的差异反映了最后一轮 SubBytes 的输入差分;
  2. 通过多组故障对建立方程约束,逐步缩小每个密钥字节的候选范围;
  3. 2~3 组有效故障对通常就能把 16 个密钥字节各自唯一确定(为了稳妥,我们取了 24 组);
  4. 得到最后一轮轮密钥后,通过 AES 密钥扩展的逆运算,还原出原始的 128 位主密钥。

五、实验结果

多次注入得到24个有效故障对:

用收集到的故障对反推 AES 密钥:

最后将恢复出来的密钥裹上 flag{} 得到 flag{3e0d16a0a614c45b423628799b22f3de},通过串口发送即可点亮 PB0: