夜雨聆风点击上方蓝字关注我们
上一篇我们深度拆解了多患者伤害视图，今天来聊另一张容易被低估实则至关重要的架构视图——可更新性和可修补性视图。为什么说这个模块是重灾区，看几个真实案例就明白了：US Radiology因设备EOL补丁延迟11个月被罚45万美元；Medtronic CVE-2020-27252允许未签名固件上传执行；Baxter呼吸机CVE-2024-48974固件更新缺少完整性校验，可能被推送恶意固件。这些案例都指向同一个结论：补丁开发得再快，送不到设备上或者送错了，一切都是白搭。2026版指南Section V.B.2.c和Appendix 1.H已经把可更新性要求写得非常具体，今天我们就来手把手讲清楚这张图怎么画、每个环节要注意什么。
晟信信息科技
先搞懂：FDA为什么死磕“可更新性”？
FDA的核心逻辑：
"Devices should be capable of being updated in a secure and timely manner to maintain safety and effectiveness throughout the product's lifecycle."
翻译成大白话：
1. 必须能更新：设备要有接收更新的能力（存储空间、通信能力、更新机制）
2. 必须安全地更新：更新过程不能被劫持、篡改、降级
3. 必须及时地更新：补丁出来后能快速部署到现场设备
这三个要求，每一个背后都有一堆技术细节和审评关注点。
什么是“端到端”更新视图？
FDA原文要求：
"This view should describe the end-to-end process that permits software updates and patches to be provided to the device."
端到端的意思：从更新包在厂商手里生成的那一刻，到更新包成功安装在设备上并验证通过的那一刻，中间的每一个环节都要画出来、讲清楚。
端到端更新的五个阶段
FDA要求你在这张视图里，把这五个阶段全部覆盖。
更新包生成——安全的起点
FDA关心什么？
❌ 常见翻车
“我们用MD5校验一下就行了”
MD5早已被证明可被碰撞攻击，不能用于安全签名！
✅ 正确做法：
● 使用RSA-2048+或ECDSA进行数字签名
● 私钥存储在HSM或安全的密钥管理系统中
● 签名过程在隔离的、受控的环境中进行
必须在视图中体现的信息（Appendix 2）
● 签名算法名称和版本
● 密钥长度和类型
● 密钥管理和保护方式
● 私钥的访问控制流程
更新包分发——最危险的“最后一公里”
FDA关心什么？
❌ 常见翻车
“用户自己去官网下载就行了”
这种模式有三个问题：
1. 用户可能不下载（补丁部署率低）
2. 用户可能下错版本
3. 用户可能从非官方渠道下载（被篡改的风险）
✅ 正确做法：
● 设备自动检测更新、自动下载
● 或者在设备上内置可信的更新服务器地址
● 如需用户确认，提供清晰的通知和操作指引
更新包验证——信任的锚点
FDA关心什么？
❌ 常见翻车
“我们只检查版本号，不签名验证”
这是致命错误！版本号可以被轻易伪造。
“公钥就放在普通Flash里，没特殊保护”
攻击者如果获得物理访问，可能替换公钥，然后安装恶意固件。
✅ 正确做法：
● 必须进行数字签名验证
● 公钥存储在受保护的存储区域（如安全元件、OTP、写保护的Flash区域）
● 签名验证逻辑本身也应受到保护，防止被绕过
更新包安装——不能“变砖”
FDA关心什么？
必须在视图中体现的信息
● 分区方案（单分区/A/B分区/其他）
● 更新失败时的回滚机制
● 断电/中断场景的处理
● 更新过程中设备的临床状态（是否影响正常功能）
安装后验证——确认成功
FDA关心什么？
可更新性视图必须包含的信息汇总关于稿定
根据 Appendix 2 的要求，这张视图必须包含：
五个最容易翻车的可更新性问题
没有防回滚机制
攻击者拿到了旧版本的固件（已知有漏洞），通过物理访问或中间人攻击，欺骗设备“升级”到这个旧版本
✅ 正确做法：
● 设备检查版本号，拒绝安装比当前版本旧的固件
● 版本号本身应包含在签名数据中，防止篡改
更新包没有签名
“我们通过HTTPS下载，所以是安全的”
HTTPS只保护传输过程，不保护更新包本身。如果服务器被攻破，或者用户从其他渠道下载，HTTPS无能为力。
✅ 正确做法：
● 更新包必须有独立的数字签名
● 设备必须验证签名，不依赖传输层安全
不考虑更新失败场景
更新到一半断电了，设备变砖
✅ 正确做法：
● 使用A/B双分区方案
● 或者在更新前验证完整性，确保完整包已到达再开始安装
● 设计恢复模式（如通过USB恢复）
不考虑存储空间
设备存储空间太小，装不下更新包
FDA在 Appendix 1.H 里专门提到：
"This will likely necessitate the need for additional storage space and processing resources."
✅ 正确做法：
● 设计时预留足够的存储空间（包括解压后的大小）
● 或者设计流式更新/差分更新机制
用户需要做太多事
用户需要：登录网站→找下载页面→选择正确型号→下载→拷贝到U盘→插入设备→进入维护菜单→选择更新
这个流程里每一步用户都可能出错或放弃。
✅ 正确做法：
● 设备自动检测更新
● 用户只需确认（或甚至无需确认）
● 如果必须手动，简化到最少步骤
可更新性视图自检清单
提交前逐项确认：
更新包生成
● 说明了签名算法和密钥管理方式
● 私钥有安全保护（HSM或等效）
● 构建环境受控
传输路径
● 画出了端到端的完整路径
● 每个传输段都标注了加密协议（TLS版本）
● 考虑了中间节点（CDN、代理等）
验证机制
● 说明了签名验证流程
● 说明了公钥存储位置和保护方式
● 有防回滚机制
安装机制
● 说明了分区方案和原子性保证
● 有失败回滚机制
● 考虑了断电/中断场景
安装后验证
● 有自检流程
● 有成功确认和用户通知机制
异常处理
● 覆盖了主要异常场景的处理方式
总结：可更新性的“三个确保”
FDA不要求你的更新机制完美无缺——但要确保你认真设计过、充分测试过、清楚记录过。
你们的设备支持OTA更新吗？最大的技术挑战是什么？评论区聊聊！
END
公众号：晟信信息
微信号：shengxinxinxikeji
扫码添加官方微信了解更多内容～
您的推荐，我的荣幸～
