技术能力与补丁期望工作组本文件由一个开放式工作组起草,包括以下个人和组织:……草案:2017年10月31日 动机 设备激增和物联网(IoT)的发展为技术进步提供了机遇,这些进步可能极大地改善人们的生活。随着设备日益融入社会,如果没有适当的、基于风险的安全措施,个人、企业和社会的安全风险可能会增加。帮助降低风险的一个重要工具是能够通过有线和无线连接的网络远程可靠地更新设备中的软件(通常被称为“空中下载”或OTA更新)。 特定设备所需的更新过程安全级别将根据制造商独特的业务需求、资源可用性和风险承受能力而有所不同。执行基本的空中下载(OTA)更新可以不包含任何增强的更新过程安全功能;然而,此类更新可能容易受到阻止、欺骗或其他恶意攻击。如果没有安全缓解措施,更新可能会无意中降低设备的安全性。关于是否采用附加功能以增强更新过程安全性的决策应基于风险,以成本效益和优先的方式实现安全目标。 “可更新”一词对每个人来说含义并不相同。不同的人和组织可能对其含义(以及应有的含义)有自己的理解。为了更好地应对更新流程的安全风险,建立对可更新性的共同理解至关重要。这可以支持制造商、采购商和其他物联网利益相关者在进行基于风险的决策,以增强更新流程的安全性。 文件概述 本文件旨在帮助制造商识别和选择合适的、基于风险的安全功能,以减轻更新过程中的漏洞。本文的第一部分概述了说明性更新过程中的基本步骤。第二部分提供了一组制造商可根据自身业务需求和风险承受能力选择采纳的自愿流程,以提升更新过程的安全性。附录详细说明了所有步骤中普遍存在的具体安全方面和缓解措施。 值得注意的是,更新流程安全仅是提升物联网设备整体安全性的众多方面之一。设备可能存在无法通过更新合理解决的安全漏洞。此外,物理和人为安全漏洞也可能无法通过软件更新来弥补。要应对缓解物联网设备漏洞这一更大的挑战,需要采取一套协调一致的行动措施,包括行业最佳实践、设备管理及网络卫生解决方案,以及提高对特定情境风险的认知。采用最高级别的空中下载更新流程安全增强措施并不能保证设备本身的安全。因此,本自愿性指南旨在仅出于开发通用词汇表这一有限目的,以支持制造商在实施空中下载更新时提升安全性。 受众及本文件使用方法 本文件旨在为物联网设备和软件制造商提供一个通用的词汇表或语言,以便讨论空中下载更新过程中的风险缓解。一个清晰的上传更新框架,包含明确的步骤,将使能够辨别风险的决策者理解特定安全功能的价值。设备和用于制造设备组件的制造商有诸多理由对其设备的更新过程感兴趣。在多样化的物联网产品领域中共享更新过程模型能带来进一步的价值。即使设备差异很大,更新步骤和潜在的安全功能也往往相似。 制造商可以采取措施来增强其设计、生产和销售设备的安全性。自愿的硬件和软件设计指南可以帮助制造商在整个产品开发、生产、销售和支持过程中实现其独特的安全目标。请注意,本文档中的信息并非明确针对最终用户。制造商如需了解如何向最终用户传达设备可升级性,可参考通信可升级性工作组(Working Group on Communicating Upgradability)发布的《Communicating IoT Device Security Update Capability to Improve Transparency for Consumers》以获取指导。本文档也不涉及已停产设备或不再维护的遗弃设备所带来的安全风险。 本文件引用了NIST发布的自愿性指南,该指南截至2017年11月有效,旨在提供额外的背景信息和资料,以有助于提升安全性。本指南仅为示例,并可能发生变化。因此,建议读者查阅最新的相关行业指南和最佳实践,以辅助决策制定,特别是在加密方面。有关更全面的物联网安全自愿性最佳实践和指南的汇编,请参阅[引用WG1标准目录]。 本文档中的信息也可能对企业级采购流程有用。了解安全更新的重要性以及某些技术相关的风险,能够更好地指导决策。 第一部分:空中更新流程的基本步骤 更新过程可以分解为一系列线性的步骤,这些步骤大致描述了需要遵循的顺序。在实践中,更新过程中可能会出现错误,需要中止线性过程或从先前已知的状态重新启动。虽然下面列出的步骤被呈现为一系列线性过程,但请注意,在每一步,如果检测到错误或不正确的情况,过程可能需要被逆转、清理,并从已知良好状态重新开始。有关回退和恢复的更多信息,请参阅附录“失败更新回滚”部分。 每个步骤中包含的安全功能可能因制造商期望的最终安全状态而异。虽然步骤的顺序对所有风险模型都是通用的,但每个步骤中实施的安全功能最终决定了更新过程的安全级别。以下更新步骤的规范性顺序是更新过程的基本要素。 0. 创建:制造商创建形象 1.本步骤假定不在此指南的范围内,但在此处予以呈现,因为它对于此流程的初始化至关重要。 1.标识:确保更新版本的真实性和完整性 1. 制造商在更新交付物中包含一个或多个签名,用于验证更新交付物内容的真实性和完整性。 2.保护:防止更新可交付成果的暴露 3.1. 制造商将更新可交付成果提交给翻译(包括加密或混淆以防止软件镜像的暴露 发送:流动中的数据 1.更新交付内容将传达给目标系统/设备。 4. 接收:接收更新交付物目标系统/设备接收更新交付物 5. 检查:流程更新可交付成果 51. 目标系统/设备验证更新交付物的完整性2. 目标系统/设备解密/解混淆更新交付物3. 目标系统根据指示对更新图像执行任何特殊处理。 6. 发布:用户设备更新通知1. 最终用户接收更新安装通知和/或批准更新安装 7.分发:分发 1. 更新交付物被解析并分发到目标设备 2. 分发可能具有递归性质。 8.流程:流程更新镜像1. 每个目标(CPU、MCU、FPGA 等)接收其更新镜像 9.阶段:系统预更新状态1. 更新操作前需要执行的活动 10.应用:触发更新流程 1. 执行实际更新流程以安装更新镜像 11.重新验证:更新后的验证1. 每个目标验证已安装更新的完整性 12.激活:激活/启用更新代码 1. 新的更新代码实际上开始在目标上执行(假设验证成功) 13.清理工作:更新后的活动1. 确认系统运行正常 第二部分:增强空中更新流程安全性的安全功能 上述步骤对于确保更新及其过程的完整性和可靠性是必要的。然而,如果在每个步骤中都不增加特定的安全功能,那么这些步骤本身容易受到恶意行为者的攻击,并且实际上可能使目标设备在更新过程中比没有更新时更加脆弱。7 每个步骤的安全需求根据上下文、威胁等因素而有所不同。 下方我们提出一个框架,用以理解可在更新流程各阶段实施的安全功能,以提升更新过程的安全性。这些功能本身对应更新流程的各个步骤。由于安全决策应基于需求、上下文、技术能力和风险评估,因此安全功能被呈现为一个“菜单”,从基本安全功能一直到根据当前最先进的加密指南设计的、旨在抵御量子计算辅助攻击的功能。 标识:确保更新真实性和完整性 风险:如果没有进行真实性和完整性检查,就无法确认收到的内容是否为预期内容,或其是否来自预期来源。更新过程最大的风险之一可能是第三方将恶意代码推送到设备上。更改设备上的代码可能导致功能出现各种偏差,包括阻止预期操作、添加新的、不受欢迎的功能、改变机器数据流的方式,或将设备武器化以攻击其他目标。 缓解措施:通过密码学方式对更新载荷进行签名,可以保护载荷的完整性,包括防止恶意行为者进行未检测到的有意修改。它还提供了载荷来源的真实性。这与使用非密码学哈希(例如循环冗余校验(CRC)或校验和)的更传统方法不同。这些非密码学哈希可以验证载荷因自然发生损坏而产生的完整性,但很容易被恶意行为者欺骗。同样,未能使用足够强的密码学签名或哈希函数也无法完全缓解这些风险。对于较旧、较弱哈希函数,有足够动机和资源的攻击者可以生成一个与合法更新具有相同哈希值的恶意更新。 基本实现:加密签名用于检测篡改并建立更新有效载荷的来源。根据 NIST SP 800-131A,RSA的可接受密钥长度为 2048 位,ECDSA 的可接受密钥长度为 224 位,可接受的哈希函数为 SHA-2系列。8 其他计算强度较低、算法(例如 MD5、SHA-1 等哈希函数)也存在,但已被发现容易受到各种形式攻击 9。NIST SP 800-89(数字签名应用获取保证的建议)提供了关于数字签名密钥管理的建议。 保护:防止更新可交付成果的暴露 风险:此步骤指的是通过加密来提高更新内容的机密性或知识产权保护,而不是以明文形式发送。(注意:通过加密保护机密性并不等同于通过密码学哈希和签名保护完整性。)未加密发送的更新存在风险,可能导致设备中包含的代码或更新有效负载被泄露。这可能允许攻击者通过逆向工程绕过设备中的其他保护措施,从而使得现场所有类似的设备都被用于僵尸网络。对制造商而言,商业风险在于竞争对手可能从软件中提取有价值的算法或技术。 缓解:在传输前加密更新内容,并在设备上解密更新内容,可以降低更新在传输过程中被泄露的风险,无论更新交付所使用的通信路径如何。 基本实现:应用层加密用于保护更新从创建时间/地点到使用时间/地点的机密性。关于应用层加密的最佳实践可在NIST轻量级加密报告中找到。10 进一步的安全考量:一旦更新交付物被设备接收,应考虑设备设计缓解措施,以避免在更新过程中设备遭受物理攻击时,暴露已解密的更新交付物。 可选地,通信路径提供的额外加密也可以作为二级加密来实现,以在加密更新交付成果分发到设备时进一步降低暴露风险。请注意,通信路径加密仅能防止在通信路径上的信息暴露。任何中间存储位置都可能导致信息暴露(参见“数据在传输中”部分)。 发送:流动中的数据 在向设备传输更新有效载荷时,通信路径可能涉及多种截然不同的通信类型(例如以太网、蜂窝基带、卫星传输、Wi-Fi、蓝牙等),其中许多类型对更新有效载荷本身缺乏固有的安全防护或完整性校验。识别通信双方通常是建立安全通信信道的一部分,以便发送方和接收方知道彼此的身份。 风险:本步骤的风险体现在前两个步骤中:更新内容的完整性与更新内容的保密性可能受到损害。传输层认证和加密提供了额外的防护层。 基础实现:传输层加密,如TLS或BLE 4.2+,可以为端点之间提供广泛接受的安全级别。使用TLS中的证书绑定等特性可以验证源地址,而BLE中的设备配对可以验证端点。VPN也能为传输中的数据提供机密性和完整性。 进一步的安防考量:“纵深防御”,即以冗余方式叠加多种安全缓解措施,可能较为可取。\endpoint验证可通过在交付更新前,以加密方式确认终端系统/设备是正确的目标来加以改进,例如挑战/响应机制或预共享密钥。 接收:接收更新交付物 该设备接收更新。 所要求的步骤本身没有特定的设计风险。然而,应遵循正常的良好安全卫生实践,例如防范缓冲区溢出。 检查:流程更新可交付成果 为此步骤,设备确认更新有效。此步骤验证前序步骤的安全性,可能包括检查设备身份,并确认更新适用于本设备。目标系统也对更新镜像执行必要的特殊处理。这是保护设备本身的关键步骤,最终每台设备都需要保护自己免受潜在恶意更新负载的侵害,并且所有先前缓解措施都在此步骤中强制执行。 风险:除了上述关于真实性、完整性和保密性的担忧(签名)之外,还存在许多安全和性能方面的顾虑。在“降级攻击”中,恶意行为者会将一个较旧的认证更新有效载荷替换掉,从而重新引入目标系统中的已知漏洞,以便在后续攻击中加以利用。更新本身也可能配置不当,从而损害设备或其功能。 基本实现:除了上述签名和加密功能外,单调版本系统还可以防止降级攻击。 进一步的安全考量:一个能够禁止旧版本的系统需要制造商驱动的回滚更新增加一个额外步骤,并可能使用户驱动的回滚更加复杂。或者,设备可以安全地验证更新的路径和来源,以确保旧版本不是来自一个不可信的来源。 宣布:用户对设备更新的认知 制造商可能希望用户参与更新过程。更新过程可能会暂时影响设备的正常功能,或者用户可能有其他方面的兴趣。 批准自动