一种物联网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

 

原创方案，禁止转载