4. 医疗设备数据加密模式与工程实现
监护仪、输液泵、可穿戴心电贴等医疗设备在遥测链路上传输的数据，往往不是一段连续字节流，而是按固定周期打包的“数据帧”。以一台典型多参数监护仪为例，它每 100 ms 生成一帧，帧内包含心率、血氧、无创血压、呼吸率、报警状态和序列号等字段。加密这些帧时，真正需要回答的问题不是“用哪种算法”，而是“用哪种分组密码工作模式，才能同时满足机密性、完整性、抗重放和低延迟”。本节围绕 GCM、CCM、CBC 三种模式，结合监护仪数据帧加密任务，说明选择依据并给出可落地的实现路径。
一、三种模式在医疗遥测中的定位
分组密码本身只解决“一个固定长度分组如何加密”，工作模式决定“多个分组如何组织、是否附带认证、能否并行”。在医疗遥测场景中，三种模式的差异可以归纳为：
- CBC（Cipher Block Chaining）：每个明文分组先与前一个密文分组异或再加密，需要初始向量 IV，且只能串行加密。它只提供机密性，不提供完整性；若攻击者篡改密文分组，解密后对应明文会随机化，但接收方无法自动发现。CBC 适合已有成熟协议、对认证由上层单独处理的场景，例如某些旧版 HL7 传输封装。
- CCM（Counter with CBC-MAC）：先做 CBC-MAC 生成认证标签，再用 CTR 模式加密，属于“先认证后加密”的 AEAD 模式。它不需要单独填充，标签长度可选，适合资源受限的无线医疗设备，例如 802.15.4 上的 Zigbee 医疗遥测。
- GCM（Galois/Counter Mode）：基于 CTR 加密与 GHASH 认证，同样属于 AEAD，支持并行处理，吞吐高，且可把帧头、设备 ID、序列号作为附加认证数据（AAD）参与完整性校验。它适合 Wi-Fi、5G、BLE 等带宽较高、对时延敏感的监护仪遥测链路。
选择依据可以概括为三条：是否需要认证、是否允许并行/低延迟、设备算力与协议栈支持。如果帧必须防篡改且不能额外增加 MAC 计算，优先 GCM 或 CCM；如果设备只支持 AES-CBC 且上层已有 HMAC，则 CBC 仍可用，但必须保证“先加密后 MAC”或“先 MAC 后加密”的顺序正确，并防止 IV 可预测。
二、监护仪数据帧加密实战任务
假设我们面对一台通过 Wi-Fi 向中央站发送数据的监护仪，帧结构为：帧头(4B) | 设备ID(8B) | 序列号(4B) | 生理参数(40B) | 报警状态(4B) | 填充(4B)，共 64 字节。要求：每帧独立加密，接收端能验证完整性和序列号，防止重放。下面以 GCM 为例给出可执行实现。
首先确定密钥与 nonce。GCM 的 nonce 必须唯一，推荐使用 12 字节结构：设备ID(8B) + 序列号(4B)。这样每帧 nonce 不同，且接收端可依据序列号判断是否重放。密钥使用 AES-128，由设备出厂时注入的根密钥和会话随机数派生：
K_session = HKDF-SHA256(根密钥, salt=设备ID, info="monitor-telemetry-v1", L=16)
nonce = 设备ID || 序列号
AAD = 帧头 || 设备ID || 序列号
明文 = 生理参数 || 报警状态 || 填充
密文, tag = AES-128-GCM(K_session, nonce, 明文, AAD, tagLen=16)
发送帧 = 帧头 || 设备ID || 序列号 || 密文 || tag接收端收到帧后，先检查序列号是否大于本地已记录的最大序列号，若否则直接丢弃并记录重放告警；然后以相同 AAD 和 nonce 调用 GCM 解密，若 tag 校验失败则丢弃并上报完整性告警。只有两者都通过，才把生理参数送入中央站显示。
三、模式选择与参数对照
为了便于在工程中快速决策，下表给出三种模式在监护仪遥测场景下的关键参数对照。表中数值为示例建议值，实际项目应根据设备算力、协议栈和合规要求调整。
| 对比项 | GCM | CCM | CBC |
|---|---|---|---|
| 机密性 | 支持 | 支持 | 支持 |
| 完整性认证 | 内置 GHASH | 内置 CBC-MAC | 需外接 HMAC |
| 是否 AEAD | 是 | 是 | 否 |
| 并行能力 | 高 | 低（MAC 串行） | 低（串行） |
| 典型标签长度 | 16 B | 8/16 B | 无（HMAC 另计） |
| 推荐场景 | Wi-Fi/5G 监护遥测 | BLE/Zigbee 低功耗 | 旧协议兼容 |
四、结果判读与异常处理
在监护仪实际运行中，加密模块的输出应满足三个可观察指标：第一，每帧密文长度等于明文长度加 tag 长度，GCM 下为 64+16=80 字节；第二，接收端 tag 校验失败率应接近 0，若持续升高，优先检查 nonce 是否重复或 AAD 是否两端不一致；第三，序列号必须单调递增，若出现回退，说明可能发生重放或设备重启后序列号未持久化。对于报警状态字段，建议将其纳入 AAD 而非仅作为明文，这样攻击者无法在不被发现的情况下篡改报警等级。
如果设备算力有限、无法承受 GCM 的 GHASH 开销，可改用 CCM，但要注意 CCM 的 MAC 计算是串行的，帧长越大延迟越高。对于 64 字节的监护帧，CCM 与 GCM 的延迟差异通常在微秒级，实际选择更多取决于协议栈是否原生支持。若必须使用 CBC，则应在加密后立即计算 HMAC-SHA256，并采用“先加密后 MAC”的顺序，接收端先验 HMAC 再解密，避免填充 oracle 攻击。
综上，监护仪数据帧加密的工程决策可以归纳为：优先选择 AEAD 模式，GCM 适合高带宽、可并行的 Wi-Fi/5G 链路，CCM 适合低功耗短帧链路，CBC 仅作为兼容旧协议的备选且必须配合 HMAC。无论哪种模式，nonce 唯一性、AAD 覆盖关键帧头、序列号防重放，都是比算法本身更值得在实现中反复检查的环节。