设计一个安全的时效性遥控协议：对抗重放攻击
在无线遥控机器人（如竞技对战或远程操作平台）中，指令的安全性至关重要。攻击者若能截获合法遥控指令（如“开火”、“加速”），即使无法解密，也可通过重放攻击（Replay Attack）在稍后时间重复发送，造成非预期行为——例如在比赛结束后突然触发武器，或在机器人静止时强制启动电机。传统解决方案常依赖时间戳+加密，但这要求设备具备实时时钟（RTC）且与遥控端严格同步，在成本敏感、无网络授时的嵌入式场景中难以实现。
为此，我们设计了一套无需RTC、仅依赖计数器同步的时效性协议，以极低的资源开销实现强抗重放能力。
一、核心思想：用“逻辑时间”替代“物理时间”
协议的核心假设是：遥控器与机器人在通信建立后，能以大致相同的速率推进“逻辑时间”。我们引入一个共享的基准计数器（Base Counter），双方以此为起点，按固定周期（如每秒）独立递增。
具体流程如下：
握手阶段（一次性同步）
遥控器（手机/手柄）生成一个随机32位整数T0（作为初始逻辑时间），连同自身ID、会话密钥等信息，通过安全通道（如配对时的BLE加密连接）发送给机器人。
机器人收到后，记录local_base = T0，并启动本地1秒定时器。指令发送阶段
每次发送控制指令前，遥控器计算当前逻辑时间：1current_time = T0 + floor(uptime_seconds)其中
uptime_seconds是自握手以来的本地运行秒数（可通过millis()/1000获得）。
指令包结构如下：1struct SecureCommand { 2 uint32_t counter; // current_time 3 uint8_t opcode; // 操作码（如0x01=前进） 4 uint8_t payload[4]; // 参数 5 uint8_t hmac[8]; // HMAC-SHA256截断至64位 6};HMAC 使用预共享密钥（PSK）对
{counter, opcode, payload}进行签名。指令验证阶段
机器人收到指令后：- 计算自身当前逻辑时间：
my_time = local_base + get_elapsed_seconds() - 检查
abs(counter - my_time) <= 5（允许±5秒时钟漂移） - 若在窗口内，且 HMAC 验证通过，则执行指令；
- 否则，直接丢弃，不作任何响应（防止时序侧信道泄露）。
- 计算自身当前逻辑时间：
二、为何有效？
- 时效性：指令仅在发送时刻前后5秒内有效，超时即失效；
- 唯一性：即使攻击者截获指令，因
counter已过期，重放将被拒绝； - 抗篡改：HMAC 确保
counter无法被伪造或修改； - 无RTC依赖：仅需毫秒级系统时钟（所有MCU均具备），无需外部晶振或网络时间。
三、工程实现细节
- 计数器溢出处理：使用32位无符号整数，约136年才溢出，可忽略；
- 初始
T0的随机性：必须使用真随机源（如STM32的TRNG或ADC噪声），防止预测； - 时钟漂移补偿：在长连接中，可定期通过心跳包微调
local_base，但非必需； - 资源占用：HMAC-SHA256 在 Cortex-M4 上约需2–3ms（使用mbedtls优化版），对100ms级控制周期影响极小。
四、对比其他方案
表格
| 方案 | 是否需RTC | 抗重放 | MCU开销 | 实现复杂度 |
|---|---|---|---|---|
| 纯序列号（Nonce） | 否 | 弱 | 低 | 低 |
| 时间戳+加密 | 是 | 强 | 中 | 高 |
| 挑战-响应（Challenge-Response） | 否 | 强 | 高 | 高 |
| 本文方案 | 否 | 强 | 低 | 中 |
纯序列号方案易受“跳号”攻击；挑战-响应需双向交互，增加延迟；而我们的方案在单向指令流中即可实现强安全。
五、实际部署效果
该协议已应用于 GankerEX 的 BLE 遥控系统。在长达8小时的连续对战测试中，未发生一次误触发或指令丢失。即使我们将机器人置于信号屏蔽箱中10分钟后重新放出，旧指令也无法生效——系统自动拒绝了所有counter落后超过5秒的数据包。
六、总结
在嵌入式安全领域，“简单而有效”往往优于“复杂而理论完美”。本协议以计数器代替时钟、以窗口验证代替绝对同步，在几乎不增加硬件成本的前提下，构建了一道抵御重放攻击的坚实防线。它不仅适用于机器人遥控，也可推广至智能家居、工业控制等任何需要轻量级时效认证的无线场景。