嵌入式系统通信安全

Question

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

我想出的是：

我们基本上有三个通道(带外命令，http请求到互联网，http响应)，因此将存储三个独立的密钥(在组装过程中随机生成)在每个设备的基础上。

HTTP数据被加密为E(iv，key，有效载荷\ H(key，有效载荷))，其中E在CBC模式下是AES 128，H是SHA256 HMAC。嵌入侧iv以H(当前时间)的形式产生，并以清晰的方式发送，以及设备用于选择正确密钥的唯一id。在微控制器上没有RNG，所以我正在尽我所能对IV做得最好。这足够好吗？

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

我知道要把这件事做对真的很难，是我错过了什么明显的事情，还是我有任何错误的细节？

Answer 1

要查看其他人在这个空间中做了什么，您可以查看以下系统：

• MiniSec是一种用于低功耗嵌入式设备的加密数据包格式.它大约代表了这一领域最先进的状态，而且设计得很好.参见以下研究论文：
  • MiniSec:一种安全传感器网络通信体系结构。马克·卢克，吉塔·梅祖尔，禤浩焯·佩里克和维吉尔·格利戈。IPSN 2007。

• 802.15.4 (Zigbee)在低功耗嵌入式设备中有一个加密通信的分组格式 .它设计得很好，尽管有一些细节你需要注意。请参阅802.15.4的以下安全分析：
  • IEEE802.15.4网络的安全考虑。纳文·萨斯特里和大卫·瓦格纳。ACM无线安全2004。

• TinySec是一种用于传感器网络加密的分组加密方案。它很老，不提供重放保护，并且使用一种简单的密钥管理方法，可能不适合您的设置。参见以下研究论文：
  • TinySec:一种无线传感器网络链路层安全体系结构。克里斯·卡洛夫，纳文·萨斯特里和大卫·瓦格纳。SenSys，2004年。

以下是我在你的计划中发现的一些可能的弱点(这只是回答“我有什么细节错了吗？”，而不是“我该怎么办？”)：

• 您使用相同的密钥进行加密和身份验证。不是个好主意。
• 你在使用认证-然后-加密。有安全弱点。这些在实践中是否是一个问题将取决于您的数据包格式的具体情况。然而，至少在你的方案的一些可信的实例化中，会有选择-密文攻击。例如，使用一些填充方案，您将容易受到填充oracle攻击。
• 你没有防止重播的保护措施。

你应该做的是：

• 使用SSL。
• 或者，如果你不能使用SSL:遵循Thomas的建议，或者跟随我前面提到的系统的脚步--在任何一种情况下，都请一位密码专家作为顾问，以确保您做得对。

Answer 2

首先，你应该精确地定义你想要防御什么样的攻击：

• 您是否害怕那些监视传感器和服务器之间交换的消息并了解消息内容的攻击者？
• 您是否害怕冒充服务器并与传感器对话的攻击者，就像他们是服务器一样？
• 您害怕冒充传感器并向服务器发送假请求的攻击者吗？
• 您是否害怕在客户端和服务器之间丢失、复制、重播和重排序消息的攻击者？

一个对称的、只包含上述所有内容的轻量级协议--在某种程度上--看起来如下：

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

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

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

关于键:我在这里讲过双向频道。每个通道方向都需要一个键。这意味着HTTP的两个键(一个用于请求，一个用于响应)和一个用于命令通道的键，假设它是单向的(从服务器到传感器的命令，没有来自传感器的响应)。如果存储三个128位键是有问题的，您可以存储一个128位密钥(“主键”)，然后使用密钥推导函数动态地重新构建这三个键。由于您在一个受限的环境中，而且EAX只使用AES，因此我建议也使用AES :使用主密钥作为密钥，用单个原始AES调用来加密三个固定的常量值(例如"0“、"1”和"2")；这将产生三个128位块，作为通道密钥。

关于抗篡改:我假设传感器将部署在“现场”，因此攻击者可能成功地捕捉到传感器，打开它，然后尝试恢复其逻辑内容。除非传感器被特别强化以防止篡改(就像智能卡那样)，这意味着攻击者将能够学习传感器密钥，并从那时起“模仿”服务器所看到的传感器。至少，每个已部署的传感器都应该有自己的密钥，而服务器必须知道所有已部署传感器的密钥。

Answer 3

我会重新检查不具有使用SSL的连接性的问题；我不知道连接建立的频率，但是任何支持恢复的现代SSL堆栈在初始握手之后只会增加一些额外的开销。至于没有足够的马力来运行密码，你应该认真地反复检查这个假设。我没有试图解析您的设计，因为我坚持基于标准的密码不惜一切代价，但您必须提出一个强有力的论点，您没有任何基本需要的事情，SSL正在做的事情。如果您不使用SSL，您将不得不做一些事情来验证您的对等方，如果这是您的答案，那么一个静态的预共享密钥正在自找麻烦。如果密钥被泄露，你将如何更新它？

使用SSL。