物联网制造商如何远程或简单地为加密算法或安全协议打补丁或升级，以确保设备安全？

对此，大量物联网制造商有一个简单的解决方案：“不要打扰”。这些往往是为他们的设备添加默认（甚至不可更改）密码的开发人员，这首先导致了 Mirai。

正如Rory 的回答中所提到的，提供机制和实际开发时间来设计和部署修复程序需要相当大的成本。我强烈怀疑，如果没有监管压力（或消费者需求，似乎并非如此），制造商就没有动力提高产品价格以增加安全性。澳大利亚似乎正在迈出这一步，考虑对所有物联网设备实施强制性安全评级系统。

我认为对于大多数制造商来说，最好的办法是让其他人来处理安全问题。正如大多数Web开发人员使用像既定框架的Django和Ruby on Rails的，以避免使 该 同样 的错误一遍又一遍，物联网开发者也应该这样做。根据您设备的复杂程度，有多种选择：

• 高端设备可以使用Ubuntu IoT或Windows 10 IoT Core等操作系统，其中安全更新由操作系统开发人员完成并自动推送。其中大部分不是特定于物联网的，但对于使用不太可能接受任何维护的自定义内部操作系统的每个物联网设备来说，这是更可取的。

• ESP8266 模块等低端设备可能受到更多限制，因为它们无法运行如此复杂的操作系统，并且倾向于运行专门为该设备开发的代码。还有一些选项，例如提供无线固件更新的Mongoose OS

物联网制造商通常应在可用的情况下利用现有解决方案。Web 开发人员通常不会为每个新网站重新创建一个 Web 框架，那么为什么物联网会大不相同呢？Rory 的回答提供了一个很好的功能列表，这些功能应该由一个好的物联网操作系统来实现，仅仅使用“物联网操作系统”并不能解决你所有的问题。正如本 Windows IoT 指南所解释的那样，必须采取措施确保硬件和固件以及操作系统本身的安全。在这方面，Rory 的回答中的想法非常全面。

以下是我建议的操作系统的一些示例，说明它们使用哪些系统来升级安全性：

• 视窗物联网：

  • 连接到 Internet 时自动进行功能和安全更新
  • 使用 Azure IoT 套件，每台设备都有一个 X.509 证书以对集线器进行身份验证。这也确保如果一台设备受到威胁，其他设备不受影响

• Ubuntu 核心：

  • 无人值守自动更新以确保安全
  • “事务性无线更新 - 具有完整的回滚功能”

Moran于 2017 年 10 月 30 日发布了这份名为“物联网设备固件更新架构”的 IETF 草案。

在Bleeping computer 上概述的一个关键摘要是

• 即使固件二进制文件是通过蓝牙、WiFi、UART、USB 或其他介质传送的，更新机制也必须相同。
• 更新机制必须在广播类型的传递中工作，允许更新一次到达多个用户。
• 必须使用端到端安全（公钥加密）来验证和验证固件映像。
• 必须防止回滚攻击。
• 设备做出安装更新决定所需的所有信息都必须适合受限物联网设备的可用 RAM。这可以防止闪存写入耗尽。
• 更新过程中的任何时间断电不得导致设备故障。
• 固件更新机制不得要求更改现有固件文件格式。
• 新的固件更新机制必须能够与大多数物联网设备特定的小型引导加载程序一起运行。
• 更新机制必须考虑多个权限。例如，关键基础设施设备的固件更新必须由固件作者和设备所有者/运营商签署。
• 新的 IoT 固件更新架构必须支持清单文件。

这在很大程度上是一个草案，因为这是一个新领域。我的期望是，它更多地受监管而非消费者需求的驱动，因为消费者真的不关心更新或安全性，除非它们直接影响它们。这方面的任何改进都会影响设备的成本。

如果您的设备固件可以比安全远程更新所需的引导加载程序简单，则不要实施远程更新。

我知道共识是拥有一个安全且健壮的引导加载程序，具有强大的公共加密身份验证，安全翻转机制，也许是一个基本的网络堆栈，然后在其之上放置一个 RTOS，具有完整的 IP+TLS 网络堆栈，然后添加最重要的是您的应用程序。对于低成本低功耗设备来说，这简直是疯了。恕我直言，这导致产品每周更新一次，这往往会打扰用户，因为有时更新在错误的时间开始，失败或破坏某些东西。更新也会消耗大量电量，因此用户必须更频繁地充电。由于攻击面很大，安全性还远未得到保证。

您的设备正在做基本的感应/驱动，也许是一些本地触发/显示，但不多？跳过这一切。

编写裸机代码，使用非常基本的堆栈，对其进行彻底审核，如果可能，进行一些形式验证。然后您就可以相对确信您的设备在未来十年内不会出现安全问题。

如果你只有一把锤子，那么一切看起来都像钉子。这就是为什么大多数编码人员试图编写代码来保护他们不安全的现有代码。编写更少的代码并不总是自然而然的。