嵌入式系统通信安全

信息安全 密码学 加密
2021-08-16 17:00:38

我正准备开始部署一个嵌入式传感器网络，该网络连接互联网（通过蜂窝网络），并定期将私人数据报告回中央服务器。不幸的是，该设备既没有连接（非常高的延迟）也没有使用 SSL 的处理能力，所以我想我只能自己想出一些东西，这违反了密码学的第 1 条规则。

我想出了什么：

我们基本上有三个通道（带外命令、对 Internet 的 http 请求、http 响应），因此将在每个设备的基础上存储三个独立的密钥（在组装期间随机生成）。

HTTP 数据被加密为 E(iv, key, payload || H(key, payload))，其中 E 是 CBC 模式下的 AES 128，H 是 SHA256 HMAC。在嵌入式端，iv 生成为 H（当前时间）并以明文形式传输，以及用于选择正确密钥的设备唯一 id。微控制器上没有 RNG，所以我正在为 IV 尽我所能。这够好吗？

由于命令不是私有的但需要进行身份验证，因此它们作为有效负载传输 || H(key, payload) 使用与 HTTP 请求或响应不同的密钥。

我知道要做到这一点真的很难，我是否遗漏了任何明显的东西或者我有任何细节错误？

3个回答

首先，您应该准确定义您要防御的攻击类型：

  • 您是否害怕攻击者监视传感器和服务器之间交换的消息并了解消息的内容？
  • 您是否害怕冒充服务器并像服务器一样与传感器交谈的攻击者？
  • 您是否害怕冒充传感器并向服务器发送虚假请求的攻击者？
  • 您是否害怕攻击者在客户端和服务器之间丢弃、复制、重放和重新排序消息？

涵盖以上所有内容的仅对称轻量级协议（在某种程度上）如下所示：

  • 对于传感器和服务器之间的任何通信通道，都有两个服务器和传感器都知道的对称密钥，一个是服务器发送给传感器的数据，一个是传感器发送给服务器的数据。
  • 服务器或传感器发送的每条消息都使用EAX 模式下的 AES 加密。
  • EAX 模式需要非重复 IV；传感器和服务器将使用计数器。
  • 每条消息都包含该消息的 IV（计数器值），然后是消息的 AES-EAX 加密。
  • 对于每个通信通道，传感器存储它发送的消息的当前计数器值，以及它通过该通道从服务器接收的最后一条消息的 IV。
  • 当它发送新消息时，传感器会增加其计数器（针对该通道），存储新值，然后（仅在那时）将新值用作 AES-EAX 的 IV。
  • 当它收到来自服务器的消息时，传感器会检查新消息使用的 IV 是否严格大于从服务器收到的最后一条消息；传感器存储新的 IV，然后（仅在那时）解密并处理来自服务器的消息。
  • 服务器使用与传感器相同的技术（它发送的消息的计数器，从传感器的最后一条消息中保存的 IV，等等）。

假设计数器从 0 开始，这意味着传感器将发送的第一条消息将使用 1 作为 IV；第二条消息将使用 2，依此类推。服务器发送的消息也是如此。这使服务器和传感器能够检测重放消息、乱序消息和丢失消息；在这种情况下他们应该做什么由您决定。

在 EAX 上：将加密和 MAC 与给定密钥结合起来并不容易。从理论上讲，为加密和 MAC 重复使用相同的密钥是有风险的。一种经过身份验证的加密模式（如 EAX）负责处理细节。作为一个很好的奖励，EAX 不需要像 CBC 那样的统一随机、不可预测的 IV；它只要求永远不要重复 IV 值（对于给定的键），所以计数器很好 - 只要您可以以有弹性的方式存储当前的 IV 值，并在正确的时间执行。当心攻击者关闭传感器以强制 IV 重置！

关于键：我在这里谈到了双向通道。每个通道方向需要一个键。这意味着 HTTP 事物有两个键（一个用于请求，一个用于响应），一个用于命令通道，假设它是单向的（从服务器到传感器的命令，没有来自传感器的响应）。如果存储三个128位密钥是成问题的，可以存储一个单个128位的密钥（一个“主密钥”），并从该动态重建三个键，具有密钥推导函数. 由于您处于受限环境中，并且 EAX 仅使用 AES，因此我建议也使用 AES：使用主密钥作为密钥，加密三个固定常量值（例如“0”、“1”和“2”）每个的单个原始 AES 调用；这将产生三个 128 位块，它们可以作为您的频道密钥。

关于防篡改：我认为传感器将部署在“现场”，因此攻击者可能会成功捕获传感器，打开它，然后尝试恢复其逻辑内容。除非传感器经过特别加固以防篡改（就像智能卡一样），否则这意味着攻击者将能够学习传感器密钥，并从那一刻起“模拟”服务器所看到的传感器。至少，每个部署的传感器都应该有自己的密钥，服务器必须知道所有部署的传感器的密钥。

我会重新审视关于没有使用 SSL 的连接的观点；我不知道建立连接的频率，但任何支持恢复的现代 SSL 堆栈只会在初始握手后施加额外的几个数据包开销。至于没有能力运行加密货币，你应该再次认真仔细检查这个假设。我没有尝试解析你的设计，因为我不惜一切代价坚持基于标准的加密，但你必须提出一个强有力的论点，即你对 SSL 所做的事情没有任何基本需求。如果您不使用 SSL，您将不得不做一些事情来验证您的对等方，并且静态预共享密钥（如果这是您的答案）正在自找麻烦。如果密钥被泄露，您将如何更新密钥？

使用 SSL。

要查看其他人在该领域所做的工作，您可以查看以下系统：

  • MiniSec是一种用于低功耗嵌入式设备的加密数据包格式。它代表了该领域的最先进技术，并且设计精良。请参阅以下研究论文：

  • 802.15.4 (Zigbee) 具有用于在低功耗嵌入式设备之间进行加密通信的数据包格式。它的设计非常好，尽管您需要注意一些细节。请参阅以下 802.15.4 的安全分析：

  • TinySec 是一种用于在传感器网络中进行加密的数据包加密方案。它很旧，不提供重放保护，并且使用可能不适合您的设置的简单密钥管理方法。请参阅以下研究论文：

以下是我在您的方案中发现的一些可能的弱点（这只是回答“我有什么细节错误吗？”，而不是“我应该怎么做？”。）：

  • 您使用相同的密钥进行加密和身份验证。不是一个好主意。

  • 您正在使用先验证后加密。这有安全漏洞。这些在实践中是否存在问题将取决于您的数据包格式的细节。但是，至少在您的方案的一些合理实例中，会有选择密文攻击。例如，使用一些填充方案，您将容易受到填充 oracle 攻击。

  • 您无法防止重播。

你应该做什么：

  • 使用 SSL。

  • 或者，如果您不能使用 SSL：请遵循 Thomas Pornin 的建议或追随我上面提到的其中一个系统的脚步——无论哪种情况，都请聘请密码学家作为顾问，以确保您做对了。

其它你可能感兴趣的问题
上一篇在没有登录/敏感用户数据的情况下，XSS 在网络上是否危险？ 下一篇DHE 交换和客户端认证