CN115052050B - 一种基于icap协议的会话协商方法、装置及控制器 - Google Patents
一种基于icap协议的会话协商方法、装置及控制器 Download PDFInfo
- Publication number
- CN115052050B CN115052050B CN202210444654.8A CN202210444654A CN115052050B CN 115052050 B CN115052050 B CN 115052050B CN 202210444654 A CN202210444654 A CN 202210444654A CN 115052050 B CN115052050 B CN 115052050B
- Authority
- CN
- China
- Prior art keywords
- session
- negotiation
- terminal
- protocol
- communication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 31
- 238000004891 communication Methods 0.000 claims abstract description 82
- 230000004044 response Effects 0.000 claims description 38
- 230000005540 biological transmission Effects 0.000 claims description 32
- 239000003999 initiator Substances 0.000 claims description 12
- 238000012545 processing Methods 0.000 claims description 12
- 230000006835 compression Effects 0.000 claims description 8
- 238000007906 compression Methods 0.000 claims description 8
- 230000004907 flux Effects 0.000 claims description 5
- 238000011161 development Methods 0.000 abstract description 4
- 230000006870 function Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 230000008878 coupling Effects 0.000 description 2
- 238000010168 coupling process Methods 0.000 description 2
- 238000005859 coupling reaction Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000012827 research and development Methods 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000004092 self-diagnosis Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Communication Control (AREA)
Abstract
一种基于ICAP协议的会话协商方法、装置及控制器，所述协议包括协议头，所述方法包括：控制端基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；所述控制端根据协商结果与所述终端建立通信连接。本申请实施例提供的基于ICAP协议的会话协商方法，所述协议包括协议头，所述方法包括：控制端基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；所述控制端根据协商结果与所述终端建立通信连接。本申请的方法可统一OBD、VCI及其他工控产品的通信规程，减少重复开发并提高通信的稳定性。
Description
技术领域
本申请涉及工业控制领域，尤其涉及一种基于ICAP协议的会话协商方法、装置及控制器。
背景技术
现有的工控产品，如OBD(On-Board Diagnostics，车载自诊断系统)、VCI(VehicleCommunication Interface，车辆通讯接口)等，各成体系，没有统一的通信规程，各产品需各自研究开发，使得该类产品存在重复开发的现象，从而造成资源的浪费。
发明内容
本申请提供一种基于ICAP协议的会话协商方法、装置及控制器。
根据本申请的第一方面，本申请提供一种基于ICAP协议的会话协商方法，所述协议包括协议头，所述方法包括：
控制端基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；
所述控制端根据协商结果与所述终端建立通信连接。
进一步地，所述协议头包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
数据：包括有效载荷。
进一步地，所述协议头包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
命令：1字节，高2bit为命令类型，包括会话类别消息、控制传输类别消息和突发传输类别消息，低6bit为子类；
数据：包括有效载荷。
进一步地，所述会话协商包括通信速率协商和/或通信安全协商；
所述通信速率协商包括通信信道最大波特率和通信双方所能承受的最大数据通量；所述速率协商的参数包括：接收缓存和发送缓存大小；
所述通信安全协商包括，会话发起方告知接收方支持的对称加密方式，所述加密方式包括DES，3DES，AES或NONE；其中，NONE表示不加密。
进一步地，所述通过所述会话类别消息进行会话协商，具体包括以下步骤：
所述控制端向所述终端请求建立会话，开始会话协商请求；
所述控制端接收所述终端的应答通信基本信息；
所述控制端使用公钥加密种子数发出请求；
所述控制端接收所述终端使用私钥加密种子数发出应答及所述终端给出会话标识；
所述控制端使用协商密钥加密接收到的种子数和会话标识发出应答；
所述控制端接收所述终端发出的会话建立结果应答，并确认会话建立。
根据本申请的第二方面，本申请提供一种基于ICAP协议的控制器，包括：
协商模块，用于基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；
处理模块，用于根据协商结果与所述终端建立通信连接。
进一步地，所述协议包括协议头，所述协议头包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
数据：包括有效载荷。
进一步地，所述协议包括协议头，所述协议头包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
命令：1字节，高2bit为命令类型，包括会话类别消息、控制传输类别消息和突发传输类别消息，低6bit为子类；
数据：包括有效载荷。
进一步地，所述协商模块包括第一协商单元和/或第二协商单元；
所述第一协商单元，用于协商通信信道最大波特率和通信双方所能承受的最大数据通量；所述通信速率协商的参数包括：接收缓存和发送缓存大小；
所述第二协商单元，用于协商会话发起方告知接收方支持的对称加密方式，所述加密方式包括DES，3DES，AES或NONE；其中，NONE表示不加密。
进一步地，所述协商模块还包括接收单元；
所述第一协商单元，用于向所述终端请求建立会话，开始会话协商请求；
所述接收单元，用于接收所述终端的应答通信基本信息；
所述第二协商单元，用于使用公钥加密种子数发出请求；
所述接收单元，还用于接收所述终端使用私钥加密种子数发出应答及所述终端给出会话标识；
所述第二协商单元，还用于使用协商密钥加密接收到的种子数和会话标识发出应答；
所述处理模块，还用于接收所述终端发出的会话建立结果应答，并确认会话建立。
根据本申请的第三方面，本申请提供一种基于ICAP协议的会话协商装置，包括：
存储器，用于存储程序；
处理器，用于通过执行所述存储器存储的程序以实现上述的方法。
根据本申请的第四方面，本申请提供一种计算机可读存储介质，所述存储介质存有程序，所述程序能够被处理器执行以实现上述的方法。
由于采用了以上技术方案，使本申请具备的有益效果在于：
本申请实施例提供的基于ICAP协议的会话协商方法，所述协议包括协议头，所述方法包括：控制端基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；所述控制端根据协商结果与所述终端建立通信连接。本申请的方法可统一OBD、VCI及其他工控产品的通信规程，减少重复开发并提高通信的稳定性。
附图说明
图1为本申请实施例一中的方法在一种实施方式中的流程图；
图2为本申请实施例一中的方法在另一种实施方式中的流程图；
图3为本申请实施例二中的控制器在一种实施方式中的程序模块示意图；
图4为本申请实施例二中的控制器在另一种实施方式中的程序模块示意图。
具体实施方式
下面通过具体实施方式结合附图对本发明作进一步详细说明。其中不同实施方式中类似元件采用了相关联的类似的元件标号。在以下的实施方式中，很多细节描述是为了使得本申请能被更好的理解。然而，本领域技术人员可以毫不费力的认识到，其中部分特征在不同情况下是可以省略的，或者可以由其他元件、材料、方法所替代。在某些情况下，本申请相关的一些操作并没有在说明书中显示或者描述，这是为了避免本申请的核心部分被过多的描述所淹没，而对于本领域技术人员而言，详细描述这些相关操作并不是必要的，他们根据说明书中的描述以及本领域的一般技术知识即可完整了解相关操作。
另外，说明书中所描述的特点、操作或者特征可以以任意适当的方式结合形成各种实施方式。同时，方法描述中的各步骤或者动作也可以按照本领域技术人员所能显而易见的方式进行顺序调换或调整。因此，说明书和附图中的各种顺序只是为了清楚描述某一个实施例，并不意味着是必须的顺序，除非另有说明其中某个顺序是必须遵循的。
本文中为部件所编序号本身，例如“第一”、“第二”等，仅用于区分所描述的对象，不具有任何顺序或技术含义。而本申请所说“连接”、“联接”，如无特别说明，均包括直接和间接连接(联接)。
本申请中的ICAP(Industry Control Advance Communication Protocol，工业控制高级通信协议)，属于传输协议(可对应OSI模型中的网络层或传输层)。该协议目的在于统一OBD、VCI及其他工控产品的通信规程，减少重复开发并提高通信的稳定性。该协议首次应用于数控钥匙机产品的应用与机械控制模块之间的通信，目前兼顾经典蓝牙和串口通信，可扩展至USB通信及更高级的通信链路上。
实施例一：
如图1所示，本申请实施例提供的基于ICAP协议的会话协商方法，ICAP协议包括协议头，该方法包括以下步骤：
步骤101：控制端基于协议头向终端发送会话类别消息，并通过会话类别消息进行会话协商。
进一步地，会话协商包括通信速率协商和/或通信安全协商。
通信速率协商包括通信信道最大波特率和通信双方所能承受的最大数据通量；速率协商的参数包括：接收缓存和发送缓存大小。
通信安全协商包括会话发起方告知接收方支持的对称加密方式，加密方式包括DES，3DES，AES或NONE；其中，NONE表示不加密。
会话建立的第一步就是会话协商，通信双方需要对即将建立的通信信道特点进行全面地协商，并最终达成一致后通信方能建立。
通信速率协商包括通信信道最大波特率和通信双方应用本身所能承受的最大数据通量。其中信道波特率不需要传输，确定了连接方式就已经确定了最大波特率，双方都已知该参数。应用本身所能承受的最大数据通量通常和缓存大小及对缓存中数据的处理速度有关。因此速率协商的参数有2个，即通信双方的接收缓存和发送缓存大小，字节序由高到低：
| 接收缓存大小 | 发送缓存大小 |
| 2 bytes | 2 bytes |
表1速率协商参数表
通信安全协商是保密性的关键步骤，会话发起方告知接收方支持的对称加密方式，包括DES,3DES,AES，NONE。全集有4种，可以发送支持的子集。接收方根据自身情况选择其中一种加密方式，如果选择NONE，则表示不加密，消息将明文传输，该特性仅可用于特定场合，比如研发的测试阶段，一个芯片难以监听的场合为了提高通信效率。该参数采用一个字节表示被称为会话选项，3-6bit每一个bit代表一种加密方式的支持能力，如下表：
表2速率协商参数的会话选项结构
如果会话建立方强制信道加密，则将0bit设置为0，表示不支持不加密的通信，接收方将不能选择NONE加密方式，否则会话无法建立。
空闲窗口或心跳间隔协商空闲窗口是指通信活跃的度量，是总线空闲的时间，在空闲窗口内会话会一直保持有效，如果总线空闲时间超过该窗口时间，会话会失效。该数据由4个字节组成，0表示时间窗口无限长。最终结果以应答的数值为准，如果发送方给出了非0数值，接收方应答了0，发送方有权拒绝继续协商。当会话选项中的标志位选择心跳间隔时，会话维持将基于心跳，指定的数量的心跳未应答后会话失效。只能在空闲窗口和心跳间隔中二选一，默认采用心跳维持会话。会话失效后，接收到任何消息均被丢弃，不做任何应答。
步骤102：控制端根据协商结果与终端建立通信连接。
进一步地，协议头可以包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
命令：1字节，高2bit为命令类型，包括会话类别消息、控制传输类别消息和突发传输类别消息，低6bit为子类；
数据：包括有效载荷。
其中，命令字段可以和数据字段合并，即可将命令字段的内容存放在数据字段。传输层和网络层协议通信时，传输层协议或网络层协议的命令字段的内容可以包含在数据字段内，由应用层去规定其含义。
在一种实施方式中，协议头可以包括以下字段:
| 标志 | 包长度 | 协议版本 | 包属性 | 消息ID | 命令 | 数据 | crc |
| 1byte | 1-4bytes | 0-1byte | 1byte | 1-4bytes | 1byte | nbytes | 1byte |
| 0x80 | High,LOW | - | - | - | - | - | - |
表3协议头的组成结构
标志：固定0x80表示一个包开始，短距离通信时，标志可以不要。
包长度：1-4字节，整个包长度，包括包头部、数据载荷、crc，便于解析包完整性。
协议版本：0-4字节，高4位为主版本，低4位为次版本，最多支持255个版本，0保留。协议版本的设定目的在于使得协议本身具有扩展性和兼容性，消息收发者对于消息的处理必须保持一致，而该一致性的依据在于协议版本信息。本协议支持最多255个版本，其中0保留，最低从0.1开始，主版本0-0x0F，次版本1-0x0F。例如版本：0.1，1.3，15.15等。在一种实施方式中，协议头也可不包含协议版本字段，如蓝牙BLE信道，其单帧数据长度不能超过20bytes。
进一步的，在另一种实施方式中，协议头可以包括以下字段：包属性、消息ID、数据、包长度，在该实施方式中，协议头可以不包括以下字段：标志、协议版本和命令字段，如蓝牙BLE信道。
包属性可用于控制包的解析和性质。包属性控制包的解析和交互等特性，目前使用1个字节：
表4协议头的包属性字段组成结构
以上三个位域在可在该字节中任意排列，可以相邻也可以间隔排列，可以设置在高位也可以设置在低位。在一种实施方式中，最低位0表示传输模式，0表示控制传输，各类控制传输的顺序无关紧要，消息可穿插传输；1表示突发传输，突发传输表面一次需要传输大量数据，期间不能被打断，直到传输完成后才能开始控制传输或下一次突发传输。位1-2表示对称加密方式，00表示不加密，01表示DES加密，10表示3DES加密，11表示AES加密，通常加密方式是会话建立期间双方协商后的结果，不能简单的固定使用某种加密方式，这对攻击者是福音，只有动态协商加密方式才更安全。位3表示数据是否被压缩，0表示不压缩，传输的是原始字节内容，1表示采用字节压缩策略。
ID：即消息ID,高4bit为会话ID，低4位为会话期间的包序号，当低4bit到达0x0F后自动从0开始。消息ID为1-4个字节长度，在一种实施方式中，消息ID的组成结构可以如下表所示：
| 7-4 | 3-0 |
| 会话ID | 会话内消息ID |
表5协议头的消息ID字段组成结构
会话建立期间，7-4位始终为0，建立后会话ID从1开始，到达F后则循环从1开始，消息ID规则一致，即ID字段不存在等于0的情况。
命令：1字节，高2bit为命令类型，低6bit为子命令。命令采用1字节，高2bit为类型，低6bit为子类，该设计便于命令归类，使得逻辑更清晰。其结构如下：
| 值 | 名称 |
| 00 | 会话类别消息 |
| 01 | 控制传输类别消息 |
| 10 | 突发传输类别消息 |
| 11 | 保留 |
表6协议头的命令字段组成结构
消息子类全1表示该类消息应答消息，但命令字节0xFF保留，是无效消息类别，因为7-6位值11是保留值，不可能出现0xFF。会话类别消息任何应答都具有确定的子类别，目的是明确的标识会话建立过程的所有步骤，而不是模糊的一般应答。
数据：有效载荷，依据命令不同而有所差异。
crc：1字节全包数据(除crc自身外)异或值。
在一种具体实施方式中，本申请的会话类别消息的内容和二进制值的对应关系可以包括：
表7会话类别消息
心跳请求可以由应用程序根据自身特点由任何一方发起，客户端服务器模式的应用中，可由服务器或客户端发起心跳，比如嵌入式设备发起，即使会话的发起方并不是它而是上层应用，这个规定保持协议的灵活性。
进一步地，如图2所示，步骤101具体可以包括以下步骤：
步骤1011：控制端向终端请求建立会话，开始会话协商请求。
在一种实施方式中，第一请求请求参数的结构如下表所示：
| 会话选项 | 接收缓存大小 | 发送缓存大小 | 空闲时间窗口或心跳间隔，单位：毫秒 |
| 1byte | 1-4bytes | 1-4bytes | 4-8bytes |
表8第一步请求参数组成结构
其中，第一步请求请求参数的各个字段的位置无顺序要求，数据大小内容可变。接收缓存大小和发送缓存大小可只任意选一种定义，如约定接收缓存大小和发送缓存大小相同。空闲时间窗口或心跳间隔的单位也可以是微秒或纳秒，当空闲时间窗口或心跳间隔的单位为纳秒时，可提高时间精度。
第一步请求参数的会话选项组成结构如下表所示：
表9第一步请求参数的会话选项组成结构
以上四个位域可在该字节中任意排列，可以相邻也可以间隔排列，可以设置在高位也可以设置在低位。
步骤1012：控制端接收终端的应答通信基本信息。
第二应答参数组成结构如下表所示：
表10第二步应答参数组成结构
其中，第二应答参数的各个字段的位置无顺序要求，数据大小内容可变。接收缓存大小和发送缓存大小可只任意选一种定义，如约定接收缓存大小和发送缓存大小相同。空闲时间窗口或心跳间隔的单位也可以是微秒或纳秒，当空闲时间窗口或心跳间隔的单位为纳秒时，可提高时间精度。当加密方式选择NONE时，RSA公钥长度、RSA公钥内容要省略，也可用作其它用途，例如可用于携带接收终端的基本信息，比如设备序列号，可用的物理硬件信息。此时不支持加密通信，会话的后续步骤也不再需要RSA加解密的支持。
步骤1013：控制端使用公钥加密种子数发出请求。
请求参数分2种情况：支持加密和不支持加密。
支持加密，则使用第二步得到的公钥加密4字节的随机数种子。支持加密的第三步请求参数组成结构如下表所示：
| 标志 | 公钥加密数据大小 | 公钥加密数据内容 |
| 1byte | 1-4bytes | nbytes |
表11支持加密的第三步请求参数组成结构第三步请求参数中的标志字段的组成结构如下表所示：
表12支持加密的第三步请求参数中的标志字段的组成结构
上表中的各个位域可在该字节中任意排列，可以相邻也可以间隔排列，可以设置在高位也可以设置在低位。
不支持加密，则不存在随机数种子相关的信息。不支持加密的第三步请求参数组成结构如下表所示：
| 标志 | 公钥加密数据大小 | 公钥加密数据内容 |
| 1byte | 0byte | 0byte |
表13不支持加密的第三步请求参数组成结构
此时只有1字节的标志信息，其中4、5位为1表示协商可以继续下去，其中有一位为0表示协商结束，第7位始终为0。
步骤1014：控制端接收终端使用私钥加密种子数发出应答及终端给出会话标识。
不支持加密通信的会话不存在该步骤，否则数据内容格式为：
| 私钥加密数据大小 | 私钥加密数据内容 |
| 1byte | nbytes |
表14支持加密的第四步应答参数
被加密的数据格式如下表所示：
| 接收方随机数 | 会话标识ID |
| 4bytes | 1-4bytes |
表14被加密的数据格式
其中会话标识可以低4位或低1-3bytes有效，该会话标识与会话内消息编号组合生成消息ID。如果加密需要填充，则低位和低字节填充0，保持有效数据在最高位置，该规则适用于本协议其他需要填充的情况。
步骤1015：控制端使用协商密钥加密接收到的种子数和会话标识发出应答。
不支持加密通信的会话不存在该步骤，否则数据内容格式为：
| 协商生存的密钥加密数据大小 | 协商生存的密钥加密数据内容 |
| 1byte | nbytes |
表15支持加密的第五步请求参数被加密的数据格式如下表所示：
| 接收方随机数 | 会话标识ID |
| 4bytes | 1-4bytes |
表16被加密的数据组成结构
步骤1016：控制端接收终端发出的会话建立结果应答。
无论支不支持加密通信，该步骤是必须的，携带1-n个字节的数据，表明失败的原因，例如1个字节表示错误码，或多个字节表示错误的描述，目的是通知会话发起方前面的协商结果已被确认并告知对方会话是否被接受。该字节的结构如下表所示：
| 7-1 | 0 |
| 失败原因 | 0表示会话成功，1表示失败 |
表17第六步应答参数
失败原因如下表所示：
表18会话建立失败的原因
如果协商成功，对称加密的密钥要基于收发方的8个字节种子数生成，例如字节之间异或，或字节之间加减，如何生成则由应用本身根据自身需求决定。
步骤1017：控制端确认会话建立。
无论支不支持加密通信，该步骤是必须的，当不携带任何数据时，目的是通知会话接收方前面的协商结果已被确认，状态已达成一致。当携带数据时，协议的应用方可决定携带什么数据，如应答方当前的时间。步骤1016、步骤1017增强协商的可靠性，确保双方均已知晓协商的结果，无论会话是否最终协商一致均应包含该确认信息。
实施例二：
如图3、图4所示，本申请实施例提供的基于ICAP协议的控制器，其一种实施方式，包括协商模块310和处理模块320。
协商模块310，用于基于协议头向终端发送会话类别消息，并通过会话类别消息进行会话协商。
进一步地，协商模块310可以包括第一协商单元311和/或第二协商单元312；
第一协商单元311，用于协商通信信道最大波特率和通信双方所能承受的最大数据通量；通信速率协商的参数包括：接收缓存和发送缓存大小。
第二协商单元312，用于协商会话发起方告知接收方支持的对称加密方式，加密方式包括DES，3DES，AES或NONE；其中，NONE表示不加密。
会话建立的第一步就是会话协商，通信双方需要对即将建立的通信信道特点进行全面地协商，并最终达成一致后通信方能建立。
通信速率协商包括通信信道最大波特率和通信双方应用本身所能承受的最大数据通量。其中信道波特率不需要传输，确定了连接方式就已经确定了最大波特率，双方都已知该参数。应用本身所能承受的最大数据通量通常和缓存大小及对缓存中数据的处理速度有关。因此速率协商的参数有2个，即通信双方的接收缓存和发送缓存大小，字节序由高到低：
| 接收缓存大小 | 发送缓存大小 |
| 2bytes | 2bytes |
表1速率协商参数表
通信安全协商是保密性的关键步骤，会话发起方告知接收方支持的对称加密方式，包括DES,3DES,AES，NONE。全集有4种，可以发送支持的子集。接收方根据自身情况选择其中一种加密方式，如果选择NONE，则表示不加密，消息将明文传输，该特性仅可用于特定场合，比如研发的测试阶段，一个芯片难以监听的场合为了提高通信效率。该参数采用一个字节表示被称为会话选项，3-6bit每一个bit代表一种加密方式的支持能力，如下表：
表2速率协商参数的会话选项结构
如果会话建立方强制信道加密，则将0bit设置为0，表示不支持不加密的通信，接收方将不能选择NONE加密方式，否则会话无法建立。
空闲窗口或心跳间隔协商空闲窗口是指通信活跃的度量，是总线空闲的时间，在空闲窗口内会话会一直保持有效，如果总线空闲时间超过该窗口时间，会话会失效。该数据由4个字节组成，0表示时间窗口无限长。最终结果以应答的数值为准，如果发送方给出了非0数值，接收方应答了0，发送方有权拒绝继续协商。当会话选项中的标志位选择心跳间隔时，会话维持将基于心跳，指定的数量的心跳未应答后会话失效。只能在空闲窗口和心跳间隔中二选一，默认采用心跳维持会话。会话失效后，接收到任何消息均被丢弃，不做任何应答。
处理模块320，用于根据协商结果与终端建立通信连接。
进一步地，协议头可以包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
命令：1字节，高2bit为命令类型，包括会话类别消息、控制传输类别消息和突发传输类别消息，低6bit为子类；
数据：包括有效载荷。
其中，命令字段可以和数据字段合并，即可将命令字段的内容存放在数据字段。传输层和网络层协议通信时，传输层协议或网络层协议的命令字段的内容可以包含在数据字段内，由应用层去规定其含义。
在一种具体实施方式中，协议头可以包括以下字段:
| 标志 | 包长度 | 协议版本 | 包属性 | 消息ID | 命令 | 数据 | crc |
| 1byte | 1-4bytes | 0-1byte | 1byte | 1-4bytes | 1byte | nbytes | 1byte |
| 0x80 | High,LOW | - | - | - | - | - | - |
表3协议头的组成结构
标志：固定0x80表示一个包开始，短距离通信时，标志可以不要。
包长度：1-4字节，整个包长度，包括包头部、数据载荷、crc，便于解析包完整性。
协议版本：0-4字节，高4位为主版本，低4位为次版本，最多支持255个版本，0保留。协议版本的设定目的在于使得协议本身具有扩展性和兼容性，消息收发者对于消息的处理必须保持一致，而该一致性的依据在于协议版本信息。本协议支持最多255个版本，其中0保留，最低从0.1开始，主版本0-0x0F，次版本1-0x0F。例如版本：0.1，1.3，15.15等。在一种实施方式中，协议头也可不包含协议版本字段，如蓝牙BLE信道，其单帧数据长度不能超过20bytes。
进一步的，在另一种实施方式中，协议头可以包括以下字段：包属性、消息ID、数据、包长度，在该实施方式中，协议头可以不包括以下字段：标志、协议版本和命令字段，如蓝牙BLE信道。
包属性：控制包的解析和性质。包属性控制包的解析和交互等特性，目前使用1个字节：
表4协议头的包属性字段组成结构
以上三个位域在可在该字节中任意排列，可以相邻也可以间隔排列，可以设置在高位也可以设置在低位。在一种实施方式中，最低位0表示传输模式，0表示控制传输，各类控制传输的顺序无关紧要，消息可穿插传输；1表示突发传输，突发传输表面一次需要传输大量数据，期间不能被打断，直到传输完成后才能开始控制传输或下一次突发传输。位1-2表示对称加密方式，00表示不加密，01表示DES加密，10表示3DES加密，11表示AES加密，通常加密方式是会话建立期间双方协商后的结果，不能简单的固定使用某种加密方式，这对攻击者是福音，只有动态协商加密方式才更安全。位3表示数据是否被压缩，0表示不压缩，传输的是原始字节内容，1表示采用字节压缩策略。
ID：即消息ID,高4bit为会话ID，低4位为会话期间的包序号，当低4bit到达0x0F后自动从0开始。消息ID为1-4字节长度，在一种实施方式中，消息ID的组成结构如下：
| 7-4 | 3-0 |
| 会话ID | 会话内消息ID |
表5协议头的消息ID字段组成结构
会话建立期间，7-4位始终为0，建立后会话ID从1开始，到达F后则循环从1开始，消息ID规则一致，即ID字段不存在等于0的情况。
命令：1字节，高2bit为命令类型，低6bit为子命令。命令采用1字节，高2bit为类型，低6bit为子类，该设计便于命令归类，使得逻辑更清晰。其结构如下：
| 值 | 名称 |
| 00 | 会话类别消息 |
| 01 | 控制传输类别消息 |
| 10 | 突发传输类别消息 |
| 11 | 保留 |
表6协议头的命令字段组成结构
消息子类全1表示该类消息应答消息，但命令字节0xFF保留，是无效消息类别，因为7-6位值11是保留值，不可能出现0xFF。会话类别消息任何应答都具有确定的子类别，目的是明确的标识会话建立过程的所有步骤，而不是模糊的一般应答。
数据：有效载荷，依据命令不同而有所差异。
crc：1字节全包数据(除crc自身外)异或值。
在一种具体实施方式中，本申请的会话类别消息的内容和二进制值的对应关系可以包括：
表7会话类别消息
心跳请求可以由应用程序根据自身特点由任何一方发起，客户端服务器模式的应用中，可由服务器或客户端发起心跳，比如嵌入式设备发起，即使会话的发起方并不是它而是上层应用，这个规定保持协议的灵活性。
进一步地，协商模块310还可以包括接收单元313；
第一协商单元311，用于向终端请求建立会话，开始会话协商请求。
在一种实施方式中，第一步请求请求参数的结构如下表所示：
| 会话选项 | 接收缓存大小 | 发送缓存大小 | 空闲时间窗口或心跳间隔，单位：毫秒 |
| 1byte | 1-4bytes | 1-4bytes | 4-8bytes |
表8第一步请求参数组成结构
其中，第一步请求请求参数的各个字段的位置无顺序要求，数据大小内容可变。接收缓存大小和发送缓存大小可只任意选一种定义，如约定接收缓存大小和发送缓存大小相同。空闲时间窗口或心跳间隔的单位也可以是微秒或纳秒，当空闲时间窗口或心跳间隔的单位为纳秒时，可提高时间精度。
会话选项组成结构如下表所示：
表9第一步请求参数的会话选项组成结构
以上四个位域可在该字节中任意排列，可以相邻也可以间隔排列，可以设置在高位也可以设置在低位。
接收单元313，用于接收终端的应答通信基本信息。
第二步应答参数组成结构如下表所示：
表10第二步应答参数组成结构
其中，第二应答参数的各个字段的位置无顺序要求，数据大小内容可变。接收缓存大小和发送缓存大小可只任意选一种定义，如约定接收缓存大小和发送缓存大小相同。空闲时间窗口或心跳间隔的单位也可以是微秒或纳秒，当空闲时间窗口或心跳间隔的单位为纳秒时，可提高时间精度。当加密方式选择NONE时，RSA公钥长度、RSA公钥内容要省略，也可用作其它用途，例如可用于携带接收终端的基本信息，比如设备序列号，可用的物理硬件信息。此时不支持加密通信，会话的后续步骤也不再需要RSA加解密的支持。
第二协商单元312，用于使用公钥加密种子数发出请求。
请求参数分2种情况：支持加密和不支持加密。
支持加密，则使用第二步得到的公钥加密4字节的随机数种子。
| 标志 | 公钥加密数据大小 | 公钥加密数据内容 |
| 1byte | 1-4bytes | nbytes |
表11支持加密的第三步请求参数组成结构
第三步请求参数中的标志字段的组成结构如下表所示：
表12支持加密的第三步请求参数中的标志字段的组成结构
上表中的各个位域可在该字节中任意排列，可以相邻也可以间隔排列，可以设置在高位也可以设置在低位。
不支持加密，则不存在随机数种子相关的信息。不支持加密的第三步请求参数组成结构如下表所示：
表13不支持加密的第三步请求参数参数组成结构
此时只有1字节的标志信息，其中4、5位为1表示协商可以继续下去，其中有一位为0表示协商结束，第7位始终为0。
接收单元313，还用于接收终端使用私钥加密种子数发出应答及终端给出会话标识。
不支持加密通信的会话不存在该步骤，否则数据内容格式为：
| 私钥加密数据大小 | 私钥加密数据内容 |
| 1byte | nbytes |
表14支持加密的第四步应答参数
被加密的数据格式如下表所示：
| 接收方随机数 | 会话标识ID |
| 4bytes | 1-4bytes |
表14被加密的数据格式
其中会话标识可以低4位或低1-3bytes有效，该会话标识与会话内消息编号组合生成消息ID。如果加密需要填充，则低位和低字节填充0，保持有效数据在最高位置，该规则适用于本协议其他需要填充的情况。
第二协商单元312，还用于使用协商密钥加密接收到的种子数和会话标识发出应答。
不支持加密通信的会话不存在该步骤，否则数据内容格式为：
| 协商生存的密钥加密数据大小 | 协商生存的密钥加密数据内容 |
| 1byte | nbytes( |
表15支持加密的第五步请求参数
被加密的数据格式如下表所示：
| 接收方随机数 | 会话标识ID |
| 4bytes | 1-4bytes |
表16被加密的数据组成结构
处理模块320，还用于接收终端发出的会话建立结果应答，并确认会话建立。
无论支不支持加密通信，该步骤是必须的，携带1-n个字节的数据，表明失败的原因，例如1个字节表示错误码，或多个字节表示错误的描述，目的是通知会话发起方前面的协商结果已被确认并告知对方会话是否被接受。该字节的结构如下表所示：
| 7-1 | 0 |
| 失败原因 | 0表示会话成功，1表示失败 |
表17第六步应答参数组成结构
失败原因如下表所示：
表18会话建立失败的原因
如果协商成功，对称加密的密钥要基于收发方的8个字节种子数生成，例如字节之间异或，或字节之间加减，如何生成则由应用本身根据自身需求决定。
无论支不支持加密通信，控制端确认会话建立是必须的，当不携带任何数据时，目的是通知会话接收方前面的协商结果已被确认，状态已达成一致。当携带数据时，协议的应用方可决定携带什么数据，如应答方当前的时间。处理模块320增强协商的可靠性，确保双方均已知晓协商的结果，无论会话是否最终协商一致均应包含该确认信息。
实施例三：
本申请实施例提供的基于ICAP的会话协商装置，其一种实施方式，包括存储器和处理器。
存储器，用于存储程序；
处理器，用于通过执行存储器存储的程序以实现实施例一中的方法。
实施例四：
一种计算机可读存储介质，存储介质存有程序，该程序能够被处理器执行以实现实施例一中的方法。
本领域技术人员可以理解，上述实施方式中各种方法的全部或部分功能可以通过硬件的方式实现，也可以通过计算机程序的方式实现。当上述实施方式中全部或部分功能通过计算机程序的方式实现时，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器、随机存储器、磁盘、光盘、硬盘等，通过计算机执行该程序以实现上述功能。例如，将程序存储在设备的存储器中，当通过处理器执行存储器中程序，即可实现上述全部或部分功能。另外，当上述实施方式中全部或部分功能通过计算机程序的方式实现时，该程序也可以存储在控制器、另一计算机、磁盘、光盘、闪存盘或移动硬盘等存储介质中，通过下载或复制保存到本地设备的存储器中，或对本地设备的系统进行版本更新，当通过处理器执行存储器中的程序时，即可实现上述实施方式中全部或部分功能。
以上应用了具体个例对本发明进行阐述，只是用于帮助理解本发明，并不用以限制本发明。对于本发明所属技术领域的技术人员，依据本发明的思想，还可以做出若干简单推演、变形或替换。
Claims (4)
1.一种基于ICAP协议的会话协商方法，其特征在于，所述协议包括协议头，所述方法包括：
控制端基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；
所述控制端根据协商结果与所述终端建立通信连接；
所述会话协商包括通信速率协商和/或通信安全协商；
所述通信速率协商包括通信信道最大波特率和通信双方所能承受的最大数据通量；所述速率协商的参数包括：接收缓存和发送缓存大小；
所述通信安全协商包括，会话发起方告知接收方支持的对称加密方式，所述加密方式包括DES，3DES，AES或NONE；其中，NONE表示不加密；
所述协议头包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
命令：1字节，高2bit为命令类型，包括会话类别消息、控制传输类别消息和突发传输类别消息，低6bit为子类；
数据：包括有效载荷；
所述通过所述会话类别消息进行会话协商，具体包括以下步骤：
所述控制端向所述终端请求建立会话，开始会话协商请求；
所述控制端接收所述终端的应答通信基本信息；
所述控制端使用公钥加密种子数发出请求；
所述控制端接收所述终端使用私钥加密种子数发出应答及所述终端给出会话标识；
所述控制端使用协商密钥加密接收到的种子数和会话标识发出应答；
所述控制端接收所述终端发出的会话建立结果应答，并确认会话建立。
2.一种基于ICAP协议的控制器，其特征在于，包括：
协商模块，用于基于协议头向终端发送会话类别消息，并通过所述会话类别消息进行会话协商；
处理模块，用于根据协商结果与所述终端建立通信连接；
所述协商模块包括第一协商单元和/或第二协商单元；
所述第一协商单元，用于协商通信信道最大波特率和通信双方所能承受的最大数据通量；所述通信速率协商的参数包括：接收缓存和发送缓存大小；
所述第二协商单元，用于协商会话发起方告知接收方支持的对称加密方式，所述加密方式包括DES，3DES，AES或NONE；其中，NONE表示不加密；
所述协议包括协议头，所述协议头包括以下字段：
包属性，包括压缩模式、加密方式和传输模式；
消息ID：高4bit为会话ID，低4位为会话期间的包序号；
命令：1字节，高2bit为命令类型，包括会话类别消息、控制传输类别消息和突发传输类别消息，低6bit为子类；
数据：包括有效载荷；
所述协商模块还包括接收单元；
所述第一协商单元，用于向所述终端请求建立会话，开始会话协商请求；
所述接收单元，用于接收所述终端的应答通信基本信息；
所述第二协商单元，用于使用公钥加密种子数发出请求；
所述接收单元，还用于接收所述终端使用私钥加密种子数发出应答及所述终端给出会话标识；
所述第二协商单元，还用于使用协商密钥加密接收到的种子数和会话标识发出应答；
所述处理模块，还用于接收所述终端发出的会话建立结果应答，并确认会话建立。
3.一种基于ICAP协议的会话协商装置，其特征在于，包括：
存储器，用于存储程序；
处理器，用于通过执行所述存储器存储的程序以实现如权利要求1所述的方法。
4.一种计算机可读存储介质，其特征在于，包括程序，所述程序能够被处理器执行以实现如权利要求1所述的方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210444654.8A CN115052050B (zh) | 2022-04-26 | 2022-04-26 | 一种基于icap协议的会话协商方法、装置及控制器 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210444654.8A CN115052050B (zh) | 2022-04-26 | 2022-04-26 | 一种基于icap协议的会话协商方法、装置及控制器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115052050A CN115052050A (zh) | 2022-09-13 |
| CN115052050B true CN115052050B (zh) | 2024-06-28 |
Family
ID=83157791
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210444654.8A Active CN115052050B (zh) | 2022-04-26 | 2022-04-26 | 一种基于icap协议的会话协商方法、装置及控制器 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115052050B (zh) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1984132A (zh) * | 2005-12-12 | 2007-06-20 | 华为技术有限公司 | 一种对会话能力信息进行处理的方法和终端 |
| CN110224976A (zh) * | 2019-04-29 | 2019-09-10 | 北京邮电大学 | 一种加密通信方法、装置及计算机可读存储介质 |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7788502B1 (en) * | 2005-03-10 | 2010-08-31 | Xilinx, Inc. | Method and system for secure exchange of IP cores |
| CN104038931B (zh) * | 2014-05-23 | 2017-09-12 | 国家电网公司 | 基于lte网络的配用电通信系统及其通信方法 |
| CN109413123A (zh) * | 2017-08-16 | 2019-03-01 | 华为技术有限公司 | 会话保持方法及相关设备 |
| CN112787819B (zh) * | 2020-12-23 | 2022-03-15 | 郑州信大捷安信息技术股份有限公司 | 一种工业控制安全通信系统及通信方法 |
-
2022
- 2022-04-26 CN CN202210444654.8A patent/CN115052050B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1984132A (zh) * | 2005-12-12 | 2007-06-20 | 华为技术有限公司 | 一种对会话能力信息进行处理的方法和终端 |
| CN110224976A (zh) * | 2019-04-29 | 2019-09-10 | 北京邮电大学 | 一种加密通信方法、装置及计算机可读存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115052050A (zh) | 2022-09-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7805522B2 (en) | Method for the transmission of user data objects | |
| US20210219351A1 (en) | Base station and user equipment for early-data transmission in a random access procedure | |
| CN107294913A (zh) | 基于http的安全通信方法、服务端及客户端 | |
| EP2573970B1 (en) | Near field communication reader device, near field communication tag device, near field communication system and near field communication method | |
| WO2015117451A1 (zh) | 加密通信方法及通信终端和计算机存储介质 | |
| WO2011137783A1 (zh) | 一种数据处理方法、装置和系统 | |
| CN1640093B (zh) | 用于加速加密方案之间转换过程的方法和系统 | |
| WO2022042235A1 (zh) | 数据报文发送方法、处理方法、装置、设备及数据报文 | |
| US6094423A (en) | Wireless protocol method and apparatus supporting transaction requests with variable length responses | |
| WO2020177169A1 (zh) | 通信的方法、装置及系统 | |
| CN115052050B (zh) | 一种基于icap协议的会话协商方法、装置及控制器 | |
| WO2021159907A1 (zh) | 一种信息传输方法、基站及终端 | |
| CN112350823B (zh) | 车载控制器间can fd通信方法 | |
| CN115052056B (zh) | 工业控制通信方法、装置、设备及存储介质 | |
| CN109167809B (zh) | 一种物联网平台对接数据传输格式处理方法 | |
| CN113973123B (zh) | 一种多接入方式加密物联网通信方法和系统 | |
| CN115052051B (zh) | 基于icap协议的信息处理方法、系统、控制器及终端 | |
| CN112073536B (zh) | 一种实现不能直接互访网络之间安全传递处理数据的方法 | |
| CN113573252B (zh) | 数据传输方法、系统、芯片、电子设备及存储介质 | |
| CN115866013A (zh) | 一种通信节点、数据传输方法及存储介质 | |
| JP6635169B2 (ja) | 移動体通信システム、ｍｔｃ−ｉｗｆ、ｕｅ、及びそれらの方法 | |
| CN115052052A (zh) | 一种基于icap协议的信息传输方法、装置及控制器 | |
| CN111200817A (zh) | 无线设备间密钥自动协商方法 | |
| TWI836730B (zh) | 完整性保護方法和相關無線通信裝置 | |
| CN113141609B (zh) | 加密通信方法、终端 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |