CN114285591A

CN114285591A - 一种基于tcp自定义协议安全通信的设备接入平台方法

Info

Publication number: CN114285591A
Application number: CN202111233488.9A
Authority: CN
Inventors: 吴昌喜; 王保杰; 应晓峰; 夏佳; 倪秀峰; 王皓珽
Original assignee: Hangzhou Xianxin Technology Co ltd
Current assignee: Hangzhou Xianxin Technology Co ltd
Priority date: 2021-10-22
Filing date: 2021-10-22
Publication date: 2022-04-05
Anticipated expiration: 2041-10-22
Also published as: CN114285591B

Abstract

本发明公开了一种基于TCP自定义协议安全通信的设备接入平台方法，克服了现有技术设备连接入网认证安全性低对IOT平台造成损害以及上报数据不稳定的问题，设备与云端服务器之间建立TCP连接后，且智能设备与IOT平台之间进行数据上下行通信之前，需要经过认证和入网的流程；只有认证入网通过以后，才能进行上下行数据通信，针对使用环境的不同分别使用三种设备入网方法。本发明通过增加设备入网认证流程，非法设备无法直接连接IOT平台上报数据，很好的保护了IOT平台，节省了服务器的资源，同时也提高了正常设备连接IOT平台和上报数据的稳定性。

Description

一种基于TCP自定义协议安全通信的设备接入平台方法

技术领域

本发明涉及通信认证技术领域，尤其是涉及一种基于TCP自定义协议安全通信的设备接入平台方法。

背景技术

随着智能设备和互联网的发展，物联网正以前所未有的速度进入和影响我们的生活。近年来，物联网相关产品层出不穷。如智能家居、智慧医疗、共享单车、自动贩卖机等，在各式各样的物联网产品中，设备联网与云端服务器进行通信是产品最基本的需求。为此人们研发出了各种各样的通信方案和通信协议，如TCP+私有协议、MQTT、COAP、LWM2M等。不同的设备由于硬件资源与联网方式的不同，采用的通信方案也不一样。其中采用TCP自定义协议进行通信的设备不在少数，但是目前采用该种方案的产品大多关注的是设备与服务器之间的数据交互以及产品相关功能的实现，往往忽略了设备联网以后的通信安全。很多设备通过TCP的方式连上云端服务器之后就可以直接进行数据上下行通信，不仅缺少设备必要的入网流程，同时也缺乏通信安全方面的校验。

发明内容

本发明是为了克服现有技术的设备连接入网认证安全性低对IOT平台造成损害以及上报数据不稳定的问题，提供一种基于TCP自定义协议安全通信的设备接入平台方法，非法设备无法直接连接IOT平台上报数据，很好的保护了IOT平台，节省了服务器的资源，同时也提高了正常设备连接IOT平台和上报数据的稳定性。

为了实现上述目的，本发明采用以下技术方案：

一种基于TCP自定义协议安全通信的设备接入平台方法，设备与云端服务器之间建立TCP连接后，且智能设备与IOT平台之间进行数据上下行通信之前，需要经过认证和入网的流程；只有认证入网通过以后，才能进行上下行数据通信，针对使用环境的不同分别使用三种设备入网方法；

所述三种设备入网方法包括：一型一密免注册、一型一密预注册和一机一密预注册；

一型一密免注册即同一个产品下所有的设备采用相同的证书密钥连接设备接入平台，且无需预先将设备注册到设备接入平台；

一型一密预注册即同一个产品下所有的设备采用相同的证书密钥连接设备接入平台；

一机一密预注册即每个设备都采用单独的证书密钥连接设备接入平台；

智能设备与IOT平台交互流程为：

S1、智能设备请求认证平台的身份；

平台回复认证请求；

S2、智能设备向IOT平台请求入网；

IOT平台回复允许设备入网；

S3、应用数据上行；

应用数据下行。

作为优选，所述一型一密免注册设备的认证入网流程如下：

创建产品后生成产品生成证书；

设备烧录产品证书信息；

在设备认证步骤中，设备通过产品证书信息进行计算获得sign值，并缓存在本地，此时设备携带产品证书信息向平台发起认证，平台收到设备的认证请求后，通过设备携带的产品证书进行同样的计算方式计算sign，并校验设备合法性，最终将认证结果和sign值返回给设备，设备收到返回的认证结果和sign，与本地计算的sign进行比对，来确认平台是否可信；

认证通过后，设备携带产品证书向平台发起入网请求，平台收到入网请求后，进行设备认证入网以及注册流程，同时使用设备发送的产品证书计算获得交互数据所需的加密密钥Sessionkey，最终将入网结果和加密密钥返回给设备。

作为优选，所述一型一密预注册采用以下认证入网流程：

设备依旧烧录产品证书信息，但是在入网前，需要在IOT设备接入平台进行设备注册操作，设备注册后会生成一个唯一的设备密钥DeviceSercet；

一型一密预注册设备使用产品证书发起认证请求后，平台返回认证结果中携带设备密钥；设备根据收到的设备密钥，和烧录的产品证书向平台发起入网请求。

作为优选，所述一机一密预注册流程与一型一密预注册都需要在设备接入平台进行设备注册，但一机一密预注册每台设备的设备密钥都是提前烧录好的，设备自身就拥有入网所需的所有密钥信息。

作为优选，智能设备接入协议定义的完整数据帧由三部分构成，数据帧都统一使用大端模式

完整数据帧的三部分分别为：Header、Data以及MIC；

Header为协议数据帧头部，描述了接入协议相关的信息；

Data为数据域，是应用数据的载荷；

MIC是接入协议数据帧的完整性校验码。

作为优选，一型一密免注册和一机一密预注册采用以下方法认证IOT平台：智能设备在成功与IoT平台建立TCP Socket链接后，建议先向平台发送认证请求以验证平台的身份，在信任平台的身份后才进行数据交互；

智能设备认证IoT平台数据帧使用的Command为1，设备向IoT平台发起认证请求的数据帧中包含了HeaderOpts域，用于携带额外的信息，Data域为空；

设备在发送认证平台的请求数据帧之前，需要先根据AES128_Encrypt算法规则，使用ProductKey对数据帧中的Random随机数进行加密运算，然后将运算结果截取最高的4个字节作为验证签名Sign的值，并将Sign值暂时缓存到本地；

AES128_Encrypt算法为加密运算方法；

IoT平台收到设备认证平台的请求数据帧后，首先会使用同样的算法规则对数据帧中的Random随机数据进行加密运算，然后将运算结果截取最高的4个字节作为Sign的值，并将Sign值返回给设备；

IoT平台使用同样的Command1对设备进行响应，返回计算出的Sign值；

协议中HeaderCtrl字段的高四位被定义为CommandFlag，即交互指令的标志位；每条交互指令的CommandFlag作用都不一样，可用于对每条交互指令进行灵活扩展；如果具体指令的详情中没有说明CommandFlag的使用，则默认为预留位；

对于智能设备认证IOT平台指令，CommandFlag定义为平台回复设备的认证请求的响应码；智能设备收到IoT平台的响应数据帧后，如果响应码CommandFlag的值为0，则通过对比自己运算后缓存在本地的Sign值与平台计算后返回的Sign值来判定平台是否可以信任；相同则认为平台可信任，反之则认为该平台不可信任；

如果智能设备发送了认证请求，等待超时后没有收到平台的任何回复，则有可能是网络问题导致数据丢失，建议检查网络并重试。

作为优选，一型一密预注册采用以下方法认证IOT平台：智能设备在成功与IoT平台建立TCP Socket链接后，建议先向平台发送认证请求以验证平台的身份，在信任平台的身份后才进行数据交互，智能设备认证IoT平台数据帧使用的Command为15，设备向IoT平台发起认证请求的数据帧中包含了HeaderOpts域，用于携带额外的信息，Data域为空；

IoT平台收到设备认证平台的请求数据帧后，首先会使用同样的算法规则对数据帧中的Random随机数据进行加密运算，然后将运算结果截取最高的4个字节作为Sign的值，并将Sign值返回给设备，并且根据nodeEui查询该设备的DeviceSecret，然后使用同样的Command15对设备进行响应；

协议中HeaderCtrl字段的高四位被定义为CommandFlag，即交互指令的标志位；

每条交互指令的CommandFlag作用都不一样，可用于对每条交互指令进行灵活扩展；如果具体指令的详情中没有说明CommandFlag的使用，则默认为预留位；

智能设备收到IoT平台的响应数据帧后，如果响应码CommandFlag的值为0，则通过对比自己运算后缓存在本地的Sign值与平台计算后返回的Sign值来判定平台是否可以信任；相同则认为平台可信任，反之则认为该平台不可信任；如果智能设备发送了认证请求，等待超时后没有收到平台的任何回复，则是网络问题导致数据丢失，建议检查网络并重试。

作为优选，智能设备向IOT平台请求入网包括以下内容：智能设备在进行正式的数据通信之前，必须先向IoT平台请求入网；设备应主动与IoT平台建立TCP Socket链接；在成功建立链接后，设备必须向平台发送请求入网数据帧，以让平台为设备分配通信资源；否则平台将拒绝与设备进行通信，请求入网数据帧使用的Command为2；平台收到入网请求后，根据ProductID查询当前产品类型是免注册还是预注册；

IoT平台收到智能设备的入网请求数据帧并成功认证设备身份后，会为该设备分配通信资源，然后使用同样的Command2响应设备；

对于智能设备请求入网指令Join，CommandFlag定义为平台回复设备的入网请求的响应码；如果智能设备发送了入网请求，等待超时后没有收到平台的任何回复，则有可能是网络问题导致数据丢失，建议检查网络并重试；

只有响应码CommandFlag值为0的时候，响应数据帧中的HeaderOpts域所携带的SessionID才是IoT平台分配的有效的SessionID；

设备成功入网后，IoT平台返回了SessionID；

设备需要使用入网安全密钥ProductKey来计算生成后续与IoT平台进行通信过程中用于加密用户应用数据的密钥SessionKey；

智能设备的入网请求数据帧如果设置了HeaderFlag中的Mode位为1，则平台会定期检查设备的SessionKey是否过期，如果平台监测到设备的SessionKey过期，则会主动通知设备更新SessionKey；如果入网请求数据帧设置了HeaderFlag中的Mode位为0，则平台不会检查设备的SessionKey是否过期，即不开启定期更换SessionKey的功能；

如果智能设备在入网请求数据帧中设置了HeaderFlag中的Mode位为1，则表示开启定期更换SessionKey的功能；平台会定期检测SessionKey是否过期，如果检测到智能设备的SessionKey过期(默认48小时过期)，平台会主动向智能设备推送最新的SessionID；如果在入网请求数据帧中设置Mode为0，则表示关闭定期更换SessionKey的功能，平台则不会检测SessionKey是否过期，设备也不会收到更新SessionID的通知；

IoT平台主动更新设备的SessionID，命令码是Command3，智能设备收到响应数据帧后，需要使用入网安全密钥ProductKey来重新计算数据安全密钥SessionKey。

作为优选，平台查询当前产品类型为一型一密免注册时，智能设备使用ProductKey对数据帧中的OpenID、ProductID、NodeEUI以及Nonce的拼接结果进行加密运算，截取运算结果的高4bytes作为Sign的值；

平台查询当前产品类型为一型一密预注册或一机一密预注册时，智能设备使用ProductKey和DeviceSecret对数据帧中的OpenID、ProductID、NodeEUI以及Nonce的拼接结果进行加密运算，截取运算结果的高4bytes作为Sign的值。

因此，本发明具有如下有益效果：

本发明设备连接IOT平台以后在与IOT平台进行上下行通信之前，需要进行设备入网与认证的流程，通过增加设备入网认证流程，非法设备无法直接连接IOT平台上报数据，很好的保护了IOT平台，节省了服务器的资源，同时也提高了正常设备连接IOT平台和上报数据的稳定性。

附图说明

图1是智能设备与IOT平台交互流程图。

图2是一型一密免注册流程图。

图3是一型一密预注册流程图。

图4是一机一密预注册流程图。

具体实施方式

下面结合附图与具体实施方式对本发明做进一步的描述。

实施例：

本实施例提供了一种基于TCP自定义协议安全通信的设备接入平台方法，描述了设备通过TCP自定义协议安全接入云端服务器的入网和认证方式，并相应制定了一套具体的通信协议。针对不同的使用环境，云端设备接入平台提供了使用密钥认证的三种设备入网方案：一型一密免注册、一型一密预注册和一机一密预注册；

如图2所示，一型一密免注册的认证入网时序图，一型一密免注册即同一个产品下所有的设备采用相同的证书密钥连接设备接入平台，且无需预先将设备注册到设备接入平台。一型一密免注册设备的入网流程如下：

创建产品后生成产品证书(OpenID、ProductID、ProductKey)。

设备烧录产品证书信息(OpenID、ProductID、ProductKey)。

在设备认证步骤中，设备通过产品证书信息进行计算获得sign值，并缓存在本地，此时设备携带产品证书信息向平台发起认证，平台收到设备的认证请求后，通过设备携带的产品证书进行同样的计算方式计算sign，并校验设备合法性，最终将认证结果和sign值返回给设备，设备收到返回的认证结果和sign，与本地计算的sign进行比对，来确认平台是否可信。

认证通过后，设备携带产品证书(OpenID、ProductID、ProductKey)向平台发起入网请求，平台收到入网请求后，进行设备认证入网以及注册流程，同时使用设备发送的产品证书计算获得交互数据所需的加密密钥Sessionkey，最终将入网结果和加密密钥返回给设备。

如图3所示，一型一密预注册的认证入网时序图，一型一密预注册即同一个产品下所有的设备采用相同的证书密钥连接设备接入平台，但与一型一密免注册不同的是，一型一密预注册需将设备预先注册到设备接入平台。一型一密预注册流程会比免注册流程更加复杂，但是其安全性更高。通过在设备接入平台进行设备预注册流程会给每个设备生成专属的设备密钥(DeviceSercet)。

其整体流程与免注册基本相似，主要介绍下不一样的地方。

设备依旧烧录产品证书信息，但是在入网前，需要在IOT设备接入平台进行设备注册操作。设备注册后会生成一个唯一的设备密钥DeviceSercet。

一型一密预注册设备使用产品证书发起认证请求后，平台返回认证结果中携带设备密钥(DeviceSercet)

设备根据收到的设备密钥，和烧录的产品证书(OpenID、ProductID、ProductKey)向平台发起入网请求。

如图4所示，一机一密预注册完整的时序图，一机一密预注册即每个设备都采用单独的证书密钥连接设备接入平台。一机一密预注册是安全性最高的一种接入方式，但是它更多的工作量是在设备烧录过程中，每台设备都要烧录不同的设备密钥信息，这使得设备生产过程中的工作量加大。一机一密预注册流程与一型一密预注册类似，都需要在设备接入平台进行设备注册，但也有不同的地方，即为每台设备的设备密钥都是提前烧录好的，不需要通过认证流程来进行动态获取，设备自身就拥有入网所需的所有密钥信息。

如图1所示，智能设备与IOT平台之间进行数据上下行通信之前，需要经过认证和入网的流程，只有认证入网通过以后，才能进行上下行数据通信，具体流程为：智能设备请求认证平台的身份；

平台回复认证请求；

智能设备向IOT平台请求入网；

平台回复允许设备入网；

应用数据上行；

应用数据下行。

智能设备接入协议定义的完整数据帧由三部分组成：Header、Data以及MIC。Header为协议数据帧头部，描述了接入协议相关的信息；Data为数据域，是应用数据的载荷(Payload)；MIC是接入协议数据帧的完整性校验码(Message Integration Code)。完整协议数据帧格式如表格1所示：

表格1

Header	Data	MIC
			5+K bytes	N bytes	1byte

下分别为协议数据帧头部Header、数据域Data以及数据帧完整性校验码MIC的内容说明。

注明：本协议所描述的数据帧都统一使用大端模式(Big-ending)。

协议数据帧头部Header的详细内容如表格2所示：

表格2

Header内容中的各个字段说明如表格3所示：

表格3

数据帧Command指令说明如表格4所示：

表格4

Data域是客户应用数据的载荷，智能设备和IoT平台的通信服务器都会将应用数据打包到Data域中，再通过网络进行传输。Data域的内容格式如表格5所示：

表格5

Payload为应用数据的有效载荷；DataLen则标识了Payload的长度。在协议文档描述的指令中，当Data域标识为Null时，表示Data域在该帧数据中为空，即Data域的数据不存在。

智能设备与IoT平台之间所有的交互数据帧都必须有完整性校验码，增强通信数据的容错性。数据帧完整性校验码MIC的内容格式如表格6所示：

表格6

MIC
	1byte

MIC采用CRC32来将Header和Data域的所有字节拼接起来进行运算，并取运算结果的最高一个字节作为MIC的值。运算方法如下所示：

M＝CRC32(Header+Data)；

例如，计算结果为：B7 56CC 1A

则MIC的值应为：B7。

S1、智能设备认证IoT平台(Auth)流程如下：

S11、一型一密免注册和一机一密预注册适用：

智能设备在成功与IoT平台建立TCP Socket链接后，建议先向平台发送认证请求以验证平台的身份，在信任平台的身份后才进行数据交互。智能设备认证IoT平台数据帧使用的Command为1，数据帧格式和内容根据如表格7所示：

表格7

设备向IoT平台发起认证请求的数据帧中包含了HeaderOpts域，用于携带额外的信息。注意：数据帧中不包含任何应用相关的数据，即Data域为空。HeaderOpts域中包含的内容及说明如表格8所示：

表格8

HeaderOpts	说明
		OpenID	硬件设备所属厂商的唯一标识ID，固定4bytes并由IoT平台分配
ProductID	硬件设备所属产品的唯一标识ID，固定4bytes并由IoT平台分配
		Random	硬件设备请求认证平台的时候，生成4字节的随机数据

设备在发送认证平台的请求数据帧之前，需要先根据AES128_Encrypt算法规则，使用ProductKey对数据帧中的Random随机数进行加密运算，然后将运算结果截取最高的4个字节作为验证签名Sign的值，并将Sign值暂时缓存到本地。

加密运算方法如下描述(伪代码)：

加密方式：AES128_ECB_PKCS5Padding

Sign＝ENCRYPT(ProductKey,Random)；

示例如下：

ProductKey：A0 1A 24 79 67 25 73 DF 84 53 7D F4 C7 3D 3F CC

Random：43 3B 99 0C

运算结果为：45 E9 10 AC 48 EA EA 0D 38EC F8 84D3 86 7C 3C

则Sign值为运算结果高4bytes：45 E9 10 AC。

IoT平台收到设备认证平台的请求数据帧后，首先会使用同样的算法规则对数据帧中的Random随机数据进行加密运算，然后将运算结果截取最高的4个字节作为Sign的值，并将Sign值返回给设备。

IoT平台使用同样的Command(1)对设备进行响应，返回计算出的Sign值。响应设备的数据帧格式以及内容如表格9所示：

表格9

Auth指令的CommandFlag说明：

本协议中HeaderCtrl字段的高四位被定义为CommandFlag，即交互指令的标志位。每条交互指令的CommandFlag作用都不一样，可用于对每条交互指令进行灵活扩展。如果具体指令的详情中没有说明CommandFlag的使用，则默认为预留位(本协议涉及到的任何预留位都必须设置为0)。

对于智能设备认证IoT平台指令(Auth)，CommandFlag定义为平台回复设备的认证请求的响应码。响应码定义如表格10所示：

表格10

智能设备收到IoT平台的响应数据帧后，如果响应码(CommandFlag)的值为0，则通过对比自己运算后缓存在本地的Sign值与平台计算后返回的Sign值来判定平台是否可以信任；相同则认为平台可信任，反之则认为该平台不可信任。

S12、一型一密预注册适用：

智能设备在成功与IoT平台建立TCP Socket链接后，建议先向平台发送认证请求以验证平台的身份，在信任平台的身份后才进行数据交互。智能设备认证IoT平台数据帧使用的Command为15，数据帧格式和内容根据如表格11所示：

表格11

设备向IoT平台发起认证请求的数据帧中包含了HeaderOpts域，用于携带额外的信息。注意：数据帧中不包含任何应用相关的数据，即Data域为空。HeaderOpts域中包含的内容及说明如表格12所示：

表格12

加密运算方法如下描述(伪代码)：

加密方式：AES128_ECB_PKCS5Padding

Sign＝ENCRYPT(ProductKey,Random)；

示例如下：

ProductKey：A0 1A 24 79 67 25 73 DF 84 53 7D F4 C7 3D 3F CC

Random：43 3B 99 0C

运算结果为：45 E9 10 AC 48 EA EA 0D 38 EC F8 84 D3 86 7C 3C

则Sign值为运算结果高4bytes：45E9 10AC。

IoT平台收到设备认证平台的请求数据帧后，首先会使用同样的算法规则对数据帧中的Random随机数据进行加密运算，然后将运算结果截取最高的4个字节作为Sign的值，并将Sign值返回给设备。并且根据nodeEui查询该设备的DeviceSecret，然后使用同样的Command(15)对设备进行响应。响应设备的数据帧格式以及内容如表格13所示：

表格13

Auth指令的CommandFlag说明：

对于智能设备认证IoT平台指令(Auth)，CommandFlag定义为平台回复设备的认证请求的响应码。响应码定义如表格14所示：

表格14

S2、智能设备请求入网(Join)

智能设备在进行正式的数据通信之前，必须先向IoT平台请求入网。设备应主动与IoT平台建立TCP Socket链接。在成功建立链接后，设备必须向平台发送请求入网数据帧，以让平台为设备分配通信资源；否则平台将拒绝与设备进行通信。

请求入网数据帧使用的Command为2；数据帧格式和内容如表格15所示：

表格15

设备向IoT平台发起的入网请求数据帧中包含了HeaderOpts域，用于携带额外的信息。HeaderOpts域中包含的内容及说明如表格16所示：

表格16

平台收到入网请求后，根据ProductID查询当前产品类型是免注册还是预注册:

S21、一型一密免注册

智能设备使用ProductKey对数据帧中的OpenID、ProductID、NodeEUI以及Nonce的拼接结果进行加密运算，截取运算结果的高4bytes作为Sign的值。

加密运算方法如下(伪代码)：

加密方式：AES128_ECB_PKCS5Padding

Sign＝ENCRYPT(ProductKey,OpenID+ProductID+NodeEUI+Nonce)；

示例如下：

ProductKey：A0 1A24 79 67 25 73DF 84 53 7D F4 C7 3D 3F CC

OpenID：11 15 43 4B ProductID：11 1E 1B C8

NodeEui(11100001)：31 31 31 30 30 30 30 31

Nonce(123)：7B

则拼接结果为：11 15 43 4B 11 1E 1B C8 31 31 31 30 30 30 30 31 7B

加密运算结果为：

5A59C8629543138F2479A2D482CE8CA3FA55300DC69B40A93516DE439425E757

则Sign值为运算结果高4bytes：5A 59 C8 62。

S22、一型一密预注册或一机一密预注册

智能设备使用ProductKey和DeviceSecret对数据帧中的OpenID、ProductID、NodeEUI以及Nonce的拼接结果进行加密运算，截取运算结果的高4bytes作为Sign的值。

加密运算方法如下(伪代码)：

加密方式：AES128_ECB_PKCS5Padding

Sign＝ENCRYPT(ProductKey,OpenID+ProductID+DeviceSecret+Nonce)；

示例如下：

ProductKey：A0 1A 24 79 67 25 73 DF 84 53 7D F4 C7 3D 3F CC

OpenID：11 15 43 4B ProductID：11 1E 1B C8

DeviceSecret:F2 05 C3 81 36 60 A0 8A BB 8A 87 90 FA 3F A3 BA

Nonce(123)：7B

则拼接结果为：

11 15 43 4B 11 1E 1B C8 F2 05 C3 81 36 60 A0 8A BB 8A 87 90 FA 3F A3BA 7B

加密运算结果为：

611A805300FF5DA40DE11A9C6647FB30CA1447621F415393974DD7C9A76595F9

则Sign值为运算结果高4bytes：61 1A 80 53。

IoT平台收到智能设备的入网请求数据帧并成功认证设备身份后，会为该设备分配通信资源，然后使用同样的Command(2)响应设备。IoT平台响应智能设备入网请求的数据帧格式以及内容如表格17所示：

表格17

Join指令的CommandFlag说明：

对于智能设备请求入网指令(Join)，CommandFlag定义为平台回复设备的入网请求的响应码。响应码定义如表格18所示：

表格18

如果智能设备发送了入网请求，等待超时后没有收到平台的任何回复，则有可能是网络问题导致数据丢失，建议检查网络并重试。

只有响应码(CommandFlag)值为0的时候，响应数据帧中的HeaderOpts域所携带的SessionID才是IoT平台分配的有效的SessionID，说明如表格19所示：

表格19

设备成功入网后，IoT平台返回了SessionID。设备需要使用入网安全密钥ProductKey来计算生成后续与IoT平台进行通信过程中用于加密用户应用数据的密钥(SessionKey)，计算方法如下描述(伪代码)：

加密方式：AES128_ECB_PKCS5Padding

SessionKey＝ENCRYPT(ProductKey,SessionID+Nonce)；

示例如下：

ProductKey：A0 1A 24 79 67 25 73 DF 84 53 7D F4 C7 3D 3F CC

SessionID：46 55 43 4B Nonce(123)：7B

则拼接结果为：46 55 43 4B 7B

加密运算结果为：40 8C 79 0F 85 BF 60 E6 D4 F1 C1 3C 6A 5C 4C 8B

SessionKey＝408C790F85BF60E6D4F1C13C6A5C4C8B。

如果使用非加密模式进行应用数据的传输，则可以忽略此步骤，即不需要计算SessionKey的值。

特别注意：智能设备的入网请求数据帧如果设置了HeaderFlag中的Mode位为1，则平台会定期检查设备的SessionKey是否过期，如果平台监测到设备的SessionKey过期，则会主动通知设备更新SessionKey(详见4.6智能设备的SessionKey过期通知)；如果入网请求数据帧设置了HeaderFlag中的Mode位为0，则平台不会检查设备的SessionKey是否过期，即不开启定期更换SessionKey的功能。

另外：设备每次与IoT平台建立新的TCP Socket链接后(首次连接或者断线重连)，都必须向平台重新请求入网，否则平台将拒绝与设备进行通信。

S3、平台下发最新SessionID

特别注意：如果智能设备在入网请求数据帧中设置了HeaderFlag中的Mode位为1，则表示开启定期更换SessionKey的功能；平台会定期检测SessionKey是否过期，如果检测到智能设备的SessionKey过期(默认48小时过期)，平台会主动向智能设备推送最新的SessionID。如果在入网请求数据帧中设置Mode为0，则表示关闭定期更换SessionKey的功能，平台则不会检测SessionKey是否过期，设备也不会收到更新SessionID的通知。

IoT平台主动更新设备的SessionID，命令码是Command(3)，下发的数据帧格式和内容如表格20所示：

表格20

智能设备收到响应数据帧后，需要使用入网安全密钥ProductKey来重新计算数据安全密钥SessionKey。计算方法如下描述(伪代码)：

加密方式：AES128_ECB_PKCS5Padding

SessionKey＝ENCRYPT(ProductKey,SessionID+Nonce)；

示例如下：

ProductKey：A0 1A 24 79 67 25 73 DF 84 53 7D F4 C7 3D 3F CC

SessionID：46 55 43 4B Nonce(123)：7B

则拼接结果为：46 55 43 4B 7B

加密运算结果为：40 8C 79 0F 85BF 60E6 D4 F1 C1 3C 6A 5C 4C 8B

SessionKey＝408C790F85BF60E6D4F1C13C6A5C4C8B。

注意：SessionKey计算方式为AES128_Encrypt(加密)，而不是AES128_Decrypt(解密)。

根据上述方案，开发了一套基于TCP自定义协议的设备接入平台，并在多个实际项目中进行了应用，同时进行了模拟设备TCP连接上报数据的测试和抓包模拟攻击，一型一密预注册、一机一密预注册的方式都能很好的限制非法设备入网攻击，非法上报数据。

上述实施例对本发明的具体描述，只用于对本发明进行进一步说明，不能理解为对本发明保护范围的限定，本领域的技术工程师根据上述发明的内容对本发明作出一些非本质的改进和调整均落入本发明的保护范围内。

Claims

1.一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，设备与云端服务器之间建立TCP连接后，且智能设备与IOT平台之间进行数据上下行通信之前，需要经过认证和入网的流程；只有认证入网通过以后，才能进行上下行数据通信，针对使用环境的不同分别使用三种设备入网方法；

智能设备与IOT平台交互流程为：

S1、智能设备请求认证平台的身份；

平台回复认证请求；

S2、智能设备向IOT平台请求入网；

IOT平台回复允许设备入网；

S3、应用数据上行；

应用数据下行。

2.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，所述一型一密免注册设备的认证入网流程如下：

创建产品后生成产品生成证书；

设备烧录产品证书信息；

3.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，所述一型一密预注册采用以下认证入网流程：

一型一密预注册设备使用产品证书发起认证请求后，平台返回认证结果中携带设备密钥；

设备根据收到的设备密钥，和烧录的产品证书向平台发起入网请求。

4.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，所述一机一密预注册流程与一型一密预注册都需要在设备接入平台进行设备注册，但一机一密预注册每台设备的设备密钥都是提前烧录好的，设备自身就拥有入网所需的所有密钥信息。

5.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，智能设备接入协议定义的完整数据帧由三部分构成，数据帧都统一使用大端模式完整数据帧的三部分分别为：Header、Data以及MIC；

Header为协议数据帧头部，描述了接入协议相关的信息；

Data为数据域，是应用数据的载荷；

MIC是接入协议数据帧的完整性校验码。

6.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，一型一密免注册和一机一密预注册采用以下方法认证IOT平台：智能设备在成功与IoT平台建立TCP Socket链接后，建议先向平台发送认证请求以验证平台的身份，在信任平台的身份后才进行数据交互；

AES128_Encrypt算法为加密运算方法；

7.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，一型一密预注册采用以下方法认证IOT平台：智能设备在成功与IoT平台建立TCPSocket链接后，建议先向平台发送认证请求以验证平台的身份，在信任平台的身份后才进行数据交互，智能设备认证IoT平台数据帧使用的Command为15，设备向IoT平台发起认证请求的数据帧中包含了HeaderOpts域，用于携带额外的信息，Data域为空；

智能设备收到IoT平台的响应数据帧后，如果响应码CommandFlag的值为0，则通过对比自己运算后缓存在本地的Sign值与平台计算后返回的Sign值来判定平台是否可以信任；相同则认为平台可信任，反之则认为该平台不可信任；

如果智能设备发送了认证请求，等待超时后没有收到平台的任何回复，则是网络问题导致数据丢失，建议检查网络并重试。

8.根据权利要求1所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，智能设备向IOT平台请求入网包括以下内容：智能设备在进行正式的数据通信之前，必须先向IoT平台请求入网；设备应主动与IoT平台建立TCP Socket链接；在成功建立链接后，设备必须向平台发送请求入网数据帧，以让平台为设备分配通信资源；否则平台将拒绝与设备进行通信，请求入网数据帧使用的Command为2；平台收到入网请求后，根据ProductID查询当前产品类型是免注册还是预注册；

设备成功入网后，IoT平台返回了SessionID；

9.根据权利要求8所述的一种基于TCP自定义协议安全通信的设备接入平台方法，其特征是，平台查询当前产品类型为一型一密免注册时，智能设备使用ProductKey对数据帧中的OpenID、ProductID、NodeEUI以及Nonce的拼接结果进行加密运算，截取运算结果的高4bytes作为Sign的值；