保持设备安全性最新的标准

#1 楼

IoT制造商如何实现远程加密或安全协议的修补或升级，或者仅仅是为了确保设备的安全性？


许多IoT制造商拥有一个简单的解决方案：“不要打扰”。这些人往往是向其设备添加默认（甚至是不可更改）密码的开发人员，这首先导致了Mirai。

正如Rory的回答中提到的那样，提供这两种方法都需要花费大量成本。设计和部署修补程序的机制和实际开发时间。我强烈怀疑，如果没有监管压力（或消费者需求，情况似乎并非如此），制造商将没有动力提高产品价格来提高安全性。澳大利亚似乎正在通过考虑对所有物联网设备采用强制性安全评级系统来迈出这一步。

我认为对于大多数制造商而言，最好的主意是让其他人来处理安全性。正如大多数Web开发人员使用诸如Django和Ruby on Rails之类的既定框架来避免一遍又一遍地犯相同的错误一样，IoT开发人员也应这样做。根据设备的复杂性，有几种选择：


高端设备可以使用Ubuntu IoT或Windows 10 IoT Core之类的操作系统，其中安全更新由OS开发人员完成并自动推送。其中大部分不是特定于IoT的，但对于使用自定义内部操作系统且不太可能获得任何维护的每个IoT设备，它更可取。
ESP8266模块等低端设备也许是由于它们无法运行如此复杂的操作系统，并且倾向于运行专门为该设备开发的代码，因此限制更大。仍然有诸如Mongoose OS之类的选项可以提供无线固件更新

物联网制造商通常应利用可用的现有解决方案。 Web开发人员通常不会为每个新网站重新创建Web框架，那么为什么IoT应该有本质上的不同？ Rory的答案提供了出色的功能列表，这些功能应该由良好的IoT操作系统实现，而仅使用“ IoT OS”将无法解决所有问题。正如此Windows IoT指南所解释的，必须采取步骤以确保硬件和固件以及操作系统本身的安全。在这方面，罗里答案中的想法非常全面。

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



Windows IoT：



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



Ubuntu Core：



安全性的无人参与自动更新
“交易性无线更新-具有完整的回滚功能”

#2 楼

Moran于2017年10月30日发布了IETF草案题为“用于物联网设备的固件更新体系结构”。
在Bleeping计算机上概述的关键摘要是


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


这是一个初稿，因为这是一个新领域。我的期望是，监管将更多地受到法规的驱动，而不是消费者的需求，因为消费者实际上并不关心更新或安全性，除非它们直接影响更新或安全性。这方面的任何改进都会影响设备的成本。

#3 楼

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

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

您的设备正在执行基本的感应/操作，也许是一些本地触发/显示，但执行的不是很多？跳过所有内容。

编写裸机代码，使用非常基本的堆栈，对其进行彻底审核，并在可能的情况下进行一些正式的验证。这样，您就可以相对有信心在未来十年内，您的设备不会出现安全问题。

如果您只用锤子，一切看起来都像钉子。这就是大多数编码器尝试编写代码以保护其不安全的现有代码的原因。编写更少的代码并不总是自然而然的。