一种物联网M2M通信密钥协商方案

一种物联网M2M通信密钥协商方案

引言

在一个物联网网络里，当两个互不受信的节点之间，想要临时地安全通信时，需要安全地建立起一个“弱连接”，以用于受限通信，这种受限访问，体现在“资源访问”的受限，和“通信有效期”的受限。

 

问题的核心在于：互不信任的双方，如何达成可信。

 

应用到物联网领域，互不受信的两个节点之间，如何在一个不安全的链路上协商出一个临时会话密钥Kses，从而两者可以建立安全通信链路。在密钥超出生存期T后，安全链路能够中断。

 

该方案能够应用到以下场景：

1.     网关和节点之间，无需互相保存对方的根密钥，建立安全的通信链路。

2.     手机和网关之间，无需互相保存对方的根密钥，建立安全的通信链路。

3.     手机和节点之间，无需互相保存对方的根密钥，建立安全的通信链路。

4.     任意两节点之间，无需互相保存对方的根密钥，建立安全的通信链路。

方案概念

要想让互不信任的双方达成可信，一共有三种方案，分别举几个生动形象的例子来说明。

l   方案一：提前预置密钥

A、B、C、D四个地下党员互不认识，但每个人都有可能和其他三个人接头。一种简单的思路就是，每个人跟其他三个人都由组织提前约定好一个独立的暗号，见面后对得上暗号，就代表是能信任的人。

 

 

 

这种方案有两个弊端：

a)       每个人都要存储n-1个暗号，整个组织要存储的暗号量是N*(N-1)，随着组织的扩大，存储的暗号量会指数级增长。这就是密码学中著名的N2密钥分配问题。

b)      当有第n+1个地下党加入组织时，该地下党要与组织里所有人建立新的暗号。

 

 

 

 

这种方案只适用于节点规模比较小，并且不会频繁增加节点的场景。不适合大规模物联网的方案。

 

l   方案二：中间人担保

还是上面地下党的例子，A、B、C、D四个地下党员互相不认识，但是它们都认识地下党组织的领导老K，而且对老K绝对信任。当A、B、C、D中某两个党员想接头时，约定先去老K家碰个头。老K证明双方都是同一战壕的兄弟，并告诉两个人一个临时的暗号，后续一段时间内两人就可以放心的直接通信了。

 

 

这种方案完美的解决了方案一的两个问题，但是要依赖一个中心节点。

 

l   方案三：去中心化的P2P网络，区块链方案

还是上面地下党的例子，A、B、C、D四个地下党员互相不认识，并且也不存在一个大家都相信的领导老K，整个组织很庞大，而且有可能有内鬼。当A要与B通信时，A要通过组织内部专门的通信手段询问大家，B是否是组织内部的人，当组织内部的大多数人（50%以上）都确认B是组织内部的人，此时A就认为B可以值得信任了。反过来说，如果B是内鬼，就必须整个组织的内鬼数量大于真实党员数量，才能欺骗A。此问题属于经典的拜占庭将军问题。

 

 

 

这种方案，是一个完全去中心化的解决方案，但是必须网络规模足够大，使得欺骗成本很高，才能保证安全性。

 

       这三种方案各有优劣，且应用领域不同。方案一适合于节点规模小，且节点数量不会频繁变动的物联网场景。方案二对任意的物联网规模都适用，能够做到方案的通用性，而且能达到非常高的安全级别，但是依赖于一个云端中心节点，对中心节点的可靠性、性能、扩展性都有很高的要求。方案三是一个完全去中心化的解决方案，但是适用那种大规模网络的物联网应用场景。

 

本文的方案，是基于方案二来设计的。

方案设计

首先声明，该方案借鉴lorawan协议安全机制，以及Kerberos协议的思想，并充分考虑应用到物联网领域的工程可行性后进行重新设计的。

 

假设我们有这样一个物联网拓扑：物联网中两个节点A和B都在生产环节烧写好独立的AppKey：KA和KB，以及对应的设备ID：ID_A和ID_B，同时云端的密钥管理中心保存了节点A和节点B的AppKey以及对应的ID。

 

 

        节点A希望与节点B安全的通信，首先A向密钥管理中心发送密钥申请消息：，该消息告诉密钥管理中心，节点A要和节点B建立临时的受信关系，同时该消息生成了一个随机nonce rA，用于对密钥管理中心的应答消息进行验证。密钥管理中心通过权限管理中心判断双方允许点对点通信后，首先生成随机的会话密钥Kses，并指明该会话密钥的生存期T（一般是指定具体到某个时间后失效，如2017/10/30 17:00:00）。接下来密钥管理中心把用A的应用密钥KA加密生成yA，把用B的应用密钥KB加密生成yB，并把yA和yB发回给节点A，密钥管理中心的使命就结束了。

       节点A收到应答消息后，首先对yA用KA解密，得到，然后判断如果满足, 则说明该应答一定是密钥管理中心发回的。通过判断, 可确认该会话密钥确实是A和B之间的会话密钥。接下来A保存了密钥生存期T。最后，A把ID_A用新申请的会话密钥Kses加密后生成yAB，并把发送给节点B。

       节点B首先用自己的应用密钥KB解密yB，得到; 并用新得到的会话密钥Kses解密yAB，得到。接下来的判断很重要：如果，则能确认yAB和yB的合法性，因此能确认两件事情：1. yB是密钥管理中心发送的，里面包含的A、B之间会话密钥Kses是合法的；2. 自己确实是跟节点A通信。最后B保存生存期T。

 

       至此，A、B双方都安全的得到了会话密钥Kses，并且双方确认了密钥的有效期T，在Kses到期前，A、B双方可以点对点的安全通信，而不需要中心节点的参与，极大的节省了云端性能的开销。

 

重放攻击 

       想象一下如下场景，如果一个黑客C抓取A和B之间的历史加密数据，并通过某种途径，得到了一个历史会话密钥，他就可以伪装成A给B发送历史yAB和yB，由于节点资源有限，从工程角度B不可能把历史上所有的会话密钥记录下来，因此B根本无法知道这是历史会话密钥。如果没有生存期T的存在，B就会承认该密钥的有效性，从而与C建立了安全连接（想象一下如果B是某银行金库的大门开关），而有了生存期T，B如果发现密钥已经失效，则此次重放攻击不生效（极端情况下，密钥可能通信一次就失效）。

       另一种重放攻击场景，是C伪装成密钥管理中心给A节点应答和，由于每次A节点会随机生成nonce rA，因此历史数据重放攻击在A节点对nonce的确认环节无法通过。

  

总结

这个方案的巧妙之处在于：

• 两个节点之间，只要有一个节点能连接云端即可，不要求双方都必须连接云端。
• 只有会话建立初期，需要云端参与协商密钥，后续通信不需要云端参与，大大节省了云端的性能开销。
• 由云端决定密钥生存期T，并且双方无法抵赖。而不是由其中某个节点决定。想象一下，如果生存期由某个节点决定，那么如果该节点是一个恶意节点，就可能把生存期设置成无限长，使该临时会话密钥无法失效。
• 同时生存期T的存在，也可以有效的防止重放攻击。

    该方案可以作为一个基础协议，嵌入到不同的产品形态：节点、手机、网关、云端密钥管理中心等。不同的产品形态，在工程实现时可能有一些不同。例如，手机作为节点A，可能没有应用密钥，而是通过用户账户+TLS隧道的机制，跟云端建立安全隧道，因此密钥管理中心下发yA时，可以不用加密，手机端可以去掉解密环节。

 

    其次，该方案独立于各种传输协议，比如手机和网关之间可能是蓝牙、Wi-Fi传输；手机和云端可能是4G移动网络；网关和节点之间是lora协议传输，均可采用此方案。

 

    另外，根据不同应用领域的安全级别不同，做方案时，可以完全实现、部分实现、不实现该协议。比如防止重放攻击必须依赖系统时钟，在安全级别要求较低，系统资源要求较苛刻的解决方案，可以不实现防止重放攻击部分（会话密钥泄漏是一个小概率事件）。

 

作者：赵晗

邮箱：1054236085@qq.com

 

原创方案，禁止转载