OTA 更新对于连接设备的开发人员来说至关重要。在今天的文章中，我们将探讨嵌入式开发人员在实施其 OTA 解决方案时应牢记的几个最佳实践。尽管我将指出一些特定于 AWS 的最佳实践，但其中大部分都是通用的。
最佳实践1 – 加密你的固件更新
创建和测试非常耗时，并且会消耗很大一部分开发预算。软件虽然也驱动产品中的大多数功能，并且可以显着改变产品，该软件是值得通过加密保护的知识产权。
加密固件映像有几个好处。首先，它可以将你的固件二进制文件转换为看似随机或无意义的形式。这是理想的，因为开发人员不希望他们的二进制图像容易被研究、调查或逆向工程。这使某人更难窃取知识产权，并且对可能对攻击系统感兴趣的人来说更难理解。其次，加密图像意味着发送者必须拥有与解密图像的设备相匹配的某种密钥或凭证。这可以看一个简单的源来帮助验证源，尽管应该做更多的工作而不只是加密来完全验证和验证完整性，例如签署图像。
最佳实践2 – 不支持固件回滚
关于系统是否应支持固件回滚经常存在争议。回滚的论点通常是，如果固件更新出现问题，那么用户可以回滚到正在运行的旧版本。乍一看，这似乎是个好主意，但它可能是系统中的漏洞来源。例如，假设 1.7 版系统中存在允许远程攻击者访问系统的错误，新的固件版本 1.8 修复了这个缺陷。客户将他们的固件更新到 1.8 版本，但攻击者知道如果他们可以强制系统恢复到 1.7，他们就可以拥有该系统。在当今我们执行 OTA 更新的互联世界中，固件回滚是一个漏洞，因此嵌入式开发人员可以禁用它们以保护你的用户。
最佳实践3 – 保护你的引导加载程序
无线更新固件需要多个组件来确保安全且成功地完成。通常，重点是将新图像发送到设备并对其进行解密。然而，就像在传统固件更新中一样，引导加载程序仍然是更新过程的关键部分，在 OTA 更新中，引导加载程序不仅是你的传统风格，而且必须是安全的。
有很多方法可以与板载引导加载程序一起使用，但无论使用哪种方法，引导加载程序都必须是安全的。安全引导加载程序需要能够在加载之前验证固件的真实性和完整性。一些系统将使用应用程序代码来验证固件并将其安装到新的应用程序插槽中，而其他系统则完全依赖引导加载程序。在任何一种情况下，安全引导加载程序都需要能够在接受新固件映像之前验证固件的真实性和完整性。
嵌入式开发人员确保在信任链中引导加载程序内置，并且不轻易修改或更新也是一个好主意。安全引导加载程序是确保系统安全所必需的信任链中的关键组件。
最佳实践4 — 建立信任链
信任链是在启动设备时发生的一系列事件，可确保链中的每个链接都是受信任的软件。例如，如果部件出厂时带有基于硬件的信任根，以验证 MCU 来自安全来源。然后将该信任根 (RoT) 转移给开发人员，该开发人员将安全引导加载程序和安全策略编程到设备上。在引导序列期间，RoT 验证引导加载程序的完整性和真实性，然后验证任何第二阶段引导加载程序或软件的完整性和真实性，然后验证应用程序的真实性和完整性。然后应用程序验证其数据、密钥、操作参数等的真实性和完整性。
该序列创建了一个信任链，固件 OTA 更新需要和使用该链。当发出新固件请求时，应用程序必须解密图像并验证新固件的真实性和完整性是否完好无损。只有当信任链能够成功通过链中的每个环节时，才能使用新固件。最重要的是，开发人员和最终用户知道，当系统成功启动时，新固件是合法的。
结论
OTA 更新是几乎所有嵌入式开发设备的关键基础设施组件。当然，有些系统一旦部署就永远不会更新，但是，这些可能只是系统的一小部分。 OTA 更新是现场更新固件的首选机制。
发表评论 取消回复