互联互通协议安全设计

互联互通协议安全设计

1、背景：

         物联网时代即将到来，智能家居是这个时代的一个典型的应用场景，目前基于智能家居的解决方案也越来越成熟，在智能家居方案里，感知层的设备之间的互动和学习将是一种特色，这也是使得家居变得智能的手段。由于智能家居将会是一套相对复杂的系统，所以同样会面临着各种各样的安全问题，从整体上看，除了传统的互联网安全问题外，还有其独具特色的感知层设备的安全问题，本文档也主要是基于这一层面来提出和解决问题的。

2、业务需求：

         YS报警器能够接入各种类型的传感器，比如：烟雾传感和门磁等等，当传感器产生报警信号时，报警器向平台推送一条报警信息，并由平台把报警信息推送到用户客户端。其优点是支持各种传感类型的报警，缺点是报警器只能产生报警，用户无法在客户端上查看实时的现场状况，也不能执行任何操作，因此大大限制的报警器的推广和使用。

         IPC报警是一种基于视频监控报警的解决方案，该方案的基于通过视频监控上的画面识别进行报警，优点是可以看到现场的实时状况和录像回放，缺点是基于视频的分析限制了报警的类型。

         基于以上2点，YS需要设计一套协议，能够让跟让处于同一个局域网内的YS报警器和IPC产生互动，进行联动报警，即当报警器产生报警时，也能够通知IPC进行抓拍和录像，并由平台推送到用户的客户端，如下图所示：

 

3、风险分析：

         虽然互联互通协议是基于局域网设计的，但由于用户使用设备的环境我们无法预估，可能存在较复杂的情况，在此，我们假设攻击者可能和受害者在同一个局域网内（群租环境下可能性很高）可能造成的风险。

3.1、仿冒：

（1）、攻击者仿冒一个合法的Sensor向Alarm发送报警触发信号。

（2）、攻击者仿冒一个合法的Alarm向IPC发送报警触发信号。

（3）、攻击者仿冒Alarm或IPC向平台发送报警信息。

3.2、伪造：

（1）、攻击者伪造合法的sensor报文发送给Alarm。

（2）、攻击者伪造合法的Alarm报文发给IPC。

（3）、攻击者伪造合法的Alarm或IPC报警报文发送给平台。

3.3、泄密：

（1）、由于传感器功耗小，处理能力差，故不和平台进行通信，sensor和alarm建立绑定关系不依赖于平台，而是双方使用点对点的方式，通过RF信道进行绑定。RF具有辐射范围大的优点，但也意味着，当sensor第一次通过RF向alarm发送绑定数据的时候，有可能被辐射范围内的监听器监听到，进而获得双方的交换的授权信息。

关于该问题，和本人在另外一篇《Smart config安全风险分析与对策》文章中描述的问题类似，在此不再详述。

PS：绑定就是指将sensor关联到指定的alarm，即sensor将授权信息发送给alarm的过程，后续的通信，alarm将通过授权信息验证sensor的合法身份。

（2）、sensor和alarm、alarm和IPC以及alarm、IPC和平台之间通信的泄密。

（3）、设备转移或被盗窃后导致的泄密。

3.4、拒绝服务：

         参考本人另外一篇《门磁报警破解猜想》，在此不再详述。

4、解决方案设计：

4.1、解决方案分析：

         以Alarm和IPC为例，根据以上分析，其实主要面临3方面的问题：

（1）、身份认证：

         Alarm和IPC之间的身份合法性验证问题。

（2）、权限控制：

         解决Alarm和IPC都必须同属一个用户的问题。

（3）、通信安全：

         解决通信过程中发生的信息泄漏、伪造和篡改问题。

4.2、解决方案流程图：

4.2.1、设备注册和绑定：

         即一个设备必须拥有一个属主，设备添加到平台时必须归属一个用户才能够正常使用，设备被绑定后无法再被其他用户绑定，决定了其一对一的关系，同时产生了设备和服务器之间后续通信的密钥。

4.2.2、设备关联：

         即对同一个用户下的设备建立关联关系，其实际是通过平台向同一个用户下的Alarm和IPC推送互联密钥。

 

备注：

（1）、互联互通密钥应满足长度、复杂度和随机性要求，建议专用密钥发生器接口来生成，用于防止攻击者对密钥进行猜解。

（2）、密钥应设置适当有效期，从平衡用户体验角度，有效期可以设置长一些（比如3个月），防止密钥泄漏，导致攻击者可以进行长期控制。此外，当密钥过期时，还可以设计让设备自动向平台请求刷新。

4.2.3、设备通信：

 

备注：

         Alarm和IPC通信安全可以使用HMAC消息摘要算法来保证，细节可以参考本人另外一篇文章：《YS私有通信协议安全整改方案》。

4.3、问题分析：

         该方案的优点是设计和实现简单，但要求服务器能够保证将加密密钥足够快速和准确地送达被关联的设备，由于网络环境可能存在复杂的情况，这样的要求并不是总能满足。

5、增强型业务需求：

         以上方案能满足人工指定关联设备的需求，然而在实际的应用场景中，有时需要感知层的设备足够智能，即自动识别局域网内的新增设备并能够实现自动关联，满足不需要人员参与的需求。

6、增强型解决方案设计：

6.1、总体思路：

         利用各个设备和服务器之间已经协商好的通信密钥作为基础，实现协商相互之间的互联互通密钥，同时，在本方案中，发起关联请求的设备将携带服务器产生的互联密钥到被关联的设备，实现严格同步，解决了4.3描述的问题。

6.2、改进的解决方案流程图：

6.2.1、设备探测和发现：

6.2.2、设备关联：

备注：

（1）、Key_a是关联设备和服务器之间的协商密钥，Key_b是被关联设备和服务器之间的协商密钥，均在设备注册到服务器时产生（参考4.2.1），key_c是关联设备和被关联设备之间后续通信使用的密钥，当前发起关联请求时由服务器产生。

（2）、关联设备、被关联设备和平台之间的通信安全可以使用HMAC消息摘要算法来保证，细节可以参考本人另外一篇文章：《YS私有通信协议安全整改方案》。

（3）、由于关联和被关联设备在局域网内通信，保证了被关联设备能够及时获得key_c，解决了4.3描述的问题。

7、进一步改进的思考：

7.1、问题描述：

         如果局域网内同一个用户下的设备需要实现星状关联（如下图），相当于每个设备都要保存自己和其所关联的不同设备之间的通信密钥，这对于低功耗和资源少的智能设备是个巨大挑战。

7.2、解决方案：

         同一个局域网内的设备共用一个密钥，对于新增关联的设备，服务器直接下发已有的密钥。以上图为例，假设Dev1和Dev2已经建立了关联关系，服务器缓存了它们的密钥，当Dev3接入该局域网时，Dev1将自动要求和Dev3建立关联关系，权限验证通过后，服务器同样向Dev3下发Dev1和Dev2之间的通信密钥，因此，Dev1、Dev2和Dev3之间可进行任意的安全通信。

7.3、安全分析：

该方案虽然解决了性能上的问题，但安全性存在一定程度上的损失，理由如下：

（1）、由于所有设备均使用同一个密钥进行通信，意味着当某个设备被入侵导致密钥被窃取时，将对其它设备造成威胁。

（2）、由于服务器需要缓存密钥，也一定程度上增加了数据泄漏风险。