3. 固件架构设计的安全考量

医疗设备固件架构设计的安全考量，核心不是“加一个加密库”或“开一个安全启动开关”，而是把安全能力嵌入到存储布局、执行域划分、权限模型和启动时序中。对于输液泵、监护仪、除颤器、影像设备等产品，固件一旦被篡改，可能直接改变治疗输出、报警阈值或数据记录，因此架构阶段就要回答四个问题：代码和数据放在哪里、谁可以访问谁、启动时信任从哪里来、安全机制会不会破坏实时性。

分区：先定义“可写边界”，再谈升级

分区设计是固件安全架构的物理基础。典型医疗设备 MCU/MPU 内部 Flash 可划分为：BootROM 保留区、一级引导区（BL1）、二级引导区（BL2）、应用区 A/B、参数区、日志区、密钥/证书区。关键原则是：引导区与应用区分离，应用区采用 A/B 双备份，参数区与代码区分离，密钥区只读或受硬件保护。

以一款基于 Cortex-M7 的输液泵控制器为例，内部 2 MB Flash 可做如下示例划分（仅为教学假设，非实测）：

分区边界确定后，升级流程才能安全：新固件先写入非活动区，校验签名和版本后，由 BL2 更新启动标志，复位后从新分区启动。若启动失败，看门狗触发回滚到旧分区。这里的关键参数是“回滚窗口”和“启动尝试次数”，例如允许连续 3 次启动失败后自动回滚，避免设备变砖。

隔离与最小权限：让错误和攻击都受限

隔离解决的是“一个模块被攻破后能影响多大范围”。在 MPU 支持的平台上，可用 MPU 配置区域权限：应用代码区设为只读可执行（RX），参数区设为可读写但不可执行（RW + XN），日志区设为只写，密钥区设为特权只读。这样即使应用层存在缓冲区溢出，也无法直接改写引导区或执行注入代码。

最小权限则要求每个执行域只拥有完成自身任务所需的最小资源。例如：通信任务只能访问 UART/CAN 外设和网络缓冲区，不能访问 Flash 控制器；报警任务只能读取传感器数据和驱动蜂鸣器/LED，不能写参数区；升级任务只能写非活动分区，不能改 BootROM 和 BL1。实际实现中，可借助 RTOS 的任务权限、MPU 子区域和硬件信号量，把“谁能访问什么”固化成配置表，而不是依赖代码自觉。

安全启动链：从硬件信任根到应用

安全启动链的本质是“信任传递”。硬件信任根（RoT）是链条起点，通常是 BootROM 中固化的不可修改代码和其中保存的根公钥哈希。启动时，BootROM 用根公钥验证 BL1 签名，BL1 验证 BL2，BL2 验证应用区，逐级传递信任。每一级只信任下一级的签名，不信任未经验证的代码。

签名验证常用 ECDSA P-256 或 RSA-3072。以 ECDSA P-256 为例，验签时间在 100 MHz MCU 上约为几十毫秒量级，具体取决于实现和优化程度。这个时间必须纳入启动预算：如果设备要求上电后 200 ms 内进入安全状态并开始报警自检，那么验签、解密和完整性检查的总时间就不能超过预算。工程上常采用“先验签关键区、后验签非关键区”或“后台校验+运行时保护”的折中策略。

硬件信任根选型：从 MCU 内置到外部安全芯片

硬件信任根选型直接影响成本、启动时间和安全等级。常见方案有三类：一是 MCU 内置 BootROM + 一次性可编程（OTP）根公钥哈希，成本最低，适合中低风险设备；二是内置安全子系统（如 TrustZone、SESIP 认证内核），支持安全/非安全世界隔离，适合需要运行复杂协议栈的设备；三是外置安全芯片（SE）或 TPM，提供独立密钥存储和加密加速，适合对密钥保护要求极高的场景。

选型时要看四个参数：根密钥是否可被读出、是否支持安全启动、是否支持安全升级、验签性能是否满足启动预算。例如，外置 SE 通常提供 I²C/SPI 接口，验签耗时可能比 MCU 内部软件实现更短，但会增加 BOM 成本和板级空间。对于便携式输液泵，若启动预算只有 300 ms，而软件 ECDSA 验签需要 80 ms，加上外设初始化和自检，可能刚好卡线；此时可考虑硬件加密加速器或外置 SE，把验签时间压到 20 ms 以内。

与实时性约束的平衡

医疗设备对实时性的要求往往比消费电子更严格。安全机制不能成为报警延迟、治疗中断或看门狗误触发的来源。工程上常用三种平衡手段：第一，分级校验，启动时只校验关键代码和参数，非关键资源在后台校验；第二，并行化，利用 DMA 和硬件加密引擎，让验签与 Flash 读取、外设初始化重叠；第三，运行时保护，启动后通过 MPU 和看门狗持续监控，而不是把所有检查都压在启动阶段。

需要特别注意的是，安全启动失败后的行为必须明确。对于输液泵，启动失败不能简单“停在 BootROM”，而应进入安全状态：停止输注、触发声光报警、记录故障码，并允许通过授权维护通道恢复。这个状态机应在架构阶段就定义清楚，而不是留给应用层临时处理。

落地时，建议先画出一张“分区—权限—启动链”对照表，把每个分区的读写执行属性、验证责任和失败回滚策略写清楚，再据此选择信任根和验签算法。只有把安全能力固化到架构中，后续的升级流程、密钥管理和漏洞响应才有稳定的基础。