CN111245862A - System for safely receiving and sending terminal data of Internet of things - Google Patents

System for safely receiving and sending terminal data of Internet of things Download PDF

Info

Publication number
CN111245862A
CN111245862A CN202010116351.4A CN202010116351A CN111245862A CN 111245862 A CN111245862 A CN 111245862A CN 202010116351 A CN202010116351 A CN 202010116351A CN 111245862 A CN111245862 A CN 111245862A
Authority
CN
China
Prior art keywords
data
message
terminal
internet
esp
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.)
Pending
Application number
CN202010116351.4A
Other languages
Chinese (zh)
Inventor
李正宏
陈黎明
丁树业
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wuxi Aleader Intelligent Technology Co ltd
Original Assignee
Wuxi Aleader Intelligent Technology Co ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Wuxi Aleader Intelligent Technology Co ltd filed Critical Wuxi Aleader Intelligent Technology Co ltd
Priority to CN202010116351.4A priority Critical patent/CN111245862A/en
Publication of CN111245862A publication Critical patent/CN111245862A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity

Abstract

A system for safely receiving and sending terminal data of the Internet of things comprises a network protocol processing module, an access control module and a data encryption and decryption module, wherein the network protocol processing module is responsible for analyzing and reconstructing a network protocol; the access control module controls the flow passing through the safety terminal, the flow of the system and the allowed service flow can pass through the Internet of things terminal, and unauthorized illegal flow and unknown flow cannot pass through the safety terminal; the data encryption and decryption module is responsible for encrypting and decrypting the service data passing through the terminal and carrying out integrity authentication, and if the integrity authentication fails, the data packet is discarded. The data security transmission terminal can ignore the diversification of a network data application layer, encrypt and decrypt data at a data transmission layer, and ensure the integrity and non-repudiation of the data; meanwhile, the access control function is provided, the anti-attack capability of the terminal equipment is improved, and the safety of data and equipment is ensured.

Description

System for safely receiving and sending terminal data of Internet of things
Technical Field
The invention relates to the technical field of information security, in particular to a system for safely receiving and sending terminal data of an internet of things.
Background
With the wide application of network technologies, a large number of network terminals including video surveillance cameras, video conference systems, internet of things data acquisition systems and the like are deployed in enterprises, buildings and cities. During data transmission, the systems mostly adopt plaintext transmission, and transmission data is easy to steal; and generally lacks the effective safeguard means of security, lacks the effective precaution measures to attack means such as weak password, system loophole, web are leaked and attacked. In particular, in a video surveillance system, there is a risk that a camera, a surveillance video, or the like is illegally replaced or tampered.
Disclosure of Invention
The invention aims to provide a system for safely receiving and sending data of an Internet of things terminal, which aims to solve the problems of poor data transmission safety and weak attack resistance of the existing Internet of things.
The technical scheme adopted by the invention for solving the technical problems is as follows:
a system for safely receiving and sending terminal data of the Internet of things comprises a network protocol processing module, an access control module and a data encryption and decryption module, wherein the network protocol processing module is responsible for analyzing and reconstructing a network protocol; the access control module controls the flow passing through the safety terminal, the flow of the system and the allowed service flow can pass through the Internet of things terminal, and unauthorized illegal flow and unknown flow cannot pass through the safety terminal; the data encryption and decryption module is responsible for encrypting and decrypting the service data passing through the terminal and carrying out integrity authentication, and if the integrity authentication fails, the data packet is discarded;
the access control module works in the following mode: the method comprises the steps that an Internet of things terminal is connected into a network, firstly, a security gateway of a server side is logged in, and key negotiation is carried out after login bidirectional authentication;
the protocol processing module completes the functions of analyzing and reconstructing the protocol; the encryption and decryption module completes the encryption and decryption and integrity identification functions of the service data, and the encryption and decryption format of the service data adopts an ESP protocol format and an ESP tunnel mode.
Further, the access control module controls the internet of things terminal to log in the security gateway of the server, and the identity authentication process is as follows:
TokenAB=Ra||Rb||sSa(Ra||Rb)
TokenBA=Rb||Ra||sSb(Rb||Ra)
(1) the initiator B generates a random number Rb and sends the Rb to the responder A;
(2) the responder A generates a random number Ra, signs Ra | Rb to form TokenAB, and sends the TokenAB to the initiator B;
(3) the initiator B obtains the signature public key of the responder A from the white list of the trust list;
(4) the initiator B verifies the signature information in the TokenAB to form TokenBA, and the TokenBA is sent to the responder A;
(5) the responder A obtains a signature public key of the initiator B from a trust list white list;
(6) responder a verifies the signature information in TokenBA.
Further, the process of controlling the terminal of the internet of things to perform key agreement by the access control module is as follows:
(1) the initiator B generates a random number R as a session key;
(2) the initiator B obtains the encrypted public key of the responder A from the white list of the trust list;
(3) the initiator B encrypts the random number R by using the encrypted public key of the responder A and sends the ciphertext value to the responder A;
(4) the responder decrypts the random number R by using the encryption private key.
Further, the ESP header format:
(1) security parameter index SPI (32 bits): it and IP address of purpose and security agreement have marked the security alliance of this data message together, used for marking the sender and using which security tactics while processing IP data packet, know how to process the packet received after the receiver analyzes this field;
(2) sequence number (32 bits): a monotonically increasing counter, which assigns a sequence number to each packet, when both communication parties establish a Security Association (SA), the sequence number is initialized to 0, the SA is unidirectional, the counter of the outgoing/incoming SA is increased by 1 every time a packet is sent/received, and the field can be used for resisting replay attack;
(3) load data: is a variable length field which contains the initialization vector IV and the data described by the next head field, the length unit is byte, the IV is positioned at the head of the load data;
(4) filling data: if the length of the load data is not integral multiple of the packet length of the encryption algorithm, filling the insufficient part, wherein the filling takes bytes as a unit;
(5) filling length: indicating the length of the padding item in the unit of byte, wherein the range is [0, 255], ensuring that the length of the encrypted data adapts to the length of the block encryption algorithm, and 0 represents no padding byte;
(6) the next head: indicating the protocol immediately following the ESP header, this field being the value of the transport layer protocol under protection;
(7) authentication data: the variable length field is an integrity check value ICV, and is a value obtained by carrying out integrity check calculation on the rest parts of the ESP message except the ICV, the field is required to be arranged only when verification service is selected, and the length of the field is determined by a selected integrity check algorithm.
Further, the position of the ESP head:
using the tunnel mode of the ESP, the ESP protects the whole original IP message including the original internal IP header;
(1) outbound message processing
The outbound message processing comprises the processes of searching SA, packaging, message encryption, generating sequence number, calculating integrity check value and fragmentation, and the like, and the outbound message processing is carried out according to the following sequence:
(1.1) search for SA: searching for SA according to local strategy, applying ESP to an outbound message only when one IPSec realizes that the message is associated with the SA, otherwise, starting a new key exchange process to establish SA;
(1.2) packaging: in the tunnel mode, the whole original value IP data message is encapsulated into an ESP load field;
(1.3) message encryption: firstly, adding all required padding to a message, and then encrypting by using a secret key, an encryption algorithm, an algorithm mode and an IV (fourth) specified by SA (security association), wherein the encryption range comprises load data, padding, a padding length and a next header;
(1.4) generating sequence number: when an SA is established, a slow good counter of a sender is initialized to be 0, the counter is added with 1 before a message is not sent, the counter is inserted into a serial number field, and a new SA is generated before the counter reaches the maximum value;
(1.5) calculating an integrity check value: the sender calculates ICV on ESP message without identification data field, and assigns the value obtained after calculation to the identification data field;
(1.6) fragmentation: after ESP processing is carried out by one IPSec, if the length of an IP data message is found to exceed the MTU value of an output interface, the processed data message is fragmented;
(2) inbound message processing
The processing of the inbound message comprises the processes of recombining, searching SA, verifying a serial number, verifying an integrity check value, decrypting the message, reconstructing and the like, and the processing is carried out according to the following sequence:
(1) and (3) recombination: if necessary, IP data message reassembly is carried out before ESP processing, the ESP does not process the fragment message, and if one message provided for ESP processing is the fragmented IP data message, a receiving party should discard the message;
(2) and searching for SA: when a message containing an ESP header is received, a receiver searches for the SA according to a destination IP address, the ESP and the SPI, and if the search fails, the message is discarded;
(3) verifying the serial number: for each received message, the receiver should confirm that the message contains a sequence number, and the sequence number does not repeat the sequence numbers of any other received messages in the SA life cycle, otherwise, the message should be discarded;
(4) verifying the integrity check value: the receiver adopts a specified integrity check algorithm to calculate the ICV of the message, the calculated result is compared with the ICV value in the message, if the calculated result is consistent with the ICV value in the message, the received data message is valid, otherwise, the receiver should discard the received data message;
(5) message decryption: decrypting the encrypted part of the received message by using a secret key, an encryption algorithm, an algorithm mode and an IV specified by the SA, judging whether the decryption is successful according to the filling length and the filling data in the decrypted message, and discarding the message if the decryption is failed;
(6) and (3) reconstruction: and reconstructing the original IP data message for the message which is successfully decrypted.
Further, the system for securely receiving and sending the terminal data of the internet of things further comprises a key management module, wherein the key management module ensures the security of the key:
1) the signature private key and the encryption private key of the terminal of the Internet of things are stored in the security chip, and only participate in operation in the security chip and cannot be exported;
2) the working key of the terminal of the Internet of things is generated by negotiation of an encryption key and an encryption key of a communication party, and does not appear in a communication link in a plaintext form.
Further, the system for safely receiving and sending the data of the terminal of the internet of things further comprises a log management module, wherein the log management module records the daily operation of the terminal of the internet of things and is used for safety audit:
1) the safety terminal synchronously outputs detailed operation management log information and provides complete audit information;
2) and auditing operation log records of a system administrator and auditing access log records of a user are supported.
Compared with the prior art, the invention has the beneficial effects that:
the data security transmission terminal provided by the invention can ignore the diversification of a network data application layer, encrypt and decrypt data at a data transmission layer, and ensure the integrity and non-repudiation of the data; meanwhile, the access control function is provided, the anti-attack capability of the terminal equipment is improved, and the safety of data and equipment is ensured.
Drawings
Fig. 1 is a schematic diagram of a system hardware structure for securely receiving and transmitting data of an internet of things terminal;
FIG. 2 is a functional block diagram of system software for securely receiving and transmitting data of an Internet of things terminal;
FIG. 3 is a network topology diagram of a typical application of a system for securely receiving and transmitting data of an Internet of things terminal;
FIG. 4 is a schematic diagram of identity authentication of a system for securely receiving and transmitting terminal data of the Internet of things;
FIG. 5 is an ESP header format diagram of a system for securely receiving and transmitting data of an Internet of things terminal;
fig. 6 is an ESP tunnel mode diagram of a system for securely receiving and transmitting data from a terminal of the internet of things.
Detailed Description
The invention is described in further detail below with reference to the figures and specific examples. Advantages and features of the present invention will become apparent from the following description and from the claims. It is to be noted that the drawings are in a very simplified form and are not to precise scale, which is merely for the purpose of facilitating and distinctly claiming the embodiments of the present invention.
The invention provides a system for safely receiving and sending terminal data of the Internet of things, which is characterized in that a schematic diagram of a hardware structure is shown in figure 1, a functional block diagram of software is shown in figure 2, and a typical application network topology is shown in figure 3.
The internet of things terminal, namely the safety terminal hardware structure, is divided into three parts according to functions: the system comprises a processor system architecture part, a safety function part and a network interface part. The processor system architecture part comprises an ARM processor, a DDR memory and a FLASH, various basic functions and scheduling of the device are achieved, the ARM processor is preferably an i.MX6 processor, the DDR memory is preferably DDR3 grain 512MB, and the FLASH is preferably NAND FLASH 256 MB. The safety function part comprises 2 WNG4 pieces, 1 SSX1702 safety chip piece and 1 TF card, wherein WNG4 generates random numbers required by cryptographic operation, the SSX1702 safety chip realizes the calling of a system to a national cryptographic algorithm SM2/SM3/SM4, the TF card selects an intelligent cryptographic key in a TF card form authenticated by a national cryptographic authority to complete the identity authentication of a system administrator, and the SSX1702 safety chip is a macro SSX1702 safety chip; the network interface part is mainly a concrete physical implementation structure of the 2-network interface.
The security terminal comprises a network protocol processing module, an access control module and a data encryption and decryption module, wherein the network protocol processing module is responsible for analyzing and reconstructing a network protocol; the access control module realizes the control of the flow passing through the safety terminal, and the flow of the system and the allowed service flow can pass through the safety terminal; unauthorized illegal flow and unknown flow can not pass through the security terminal; and the data encryption and decryption module is responsible for encrypting and decrypting the service data passing through the terminal and carrying out integrity authentication, and if the integrity authentication fails, the data packet is discarded.
Specifically, as shown in fig. 3, the terminal of the internet of things, i.e., the security terminal of the internet of things, is connected in series in the network near the terminal device, and can encrypt the transmission data of the terminal device, protect the terminal device from being damaged by illegal attacks, and prevent the terminal device from being illegally replaced.
The working mode of the Internet of things safety terminal is as follows:
the security terminal firstly logs in a security gateway of a server side in a network, and an identity authentication process between devices formulated by a national cryptology agency follows the national standard GBT 15843.3-2016 part 3 of information technology security technology entity authentication: the method defined in section 5.3.3 of the mechanism for digital signature technology. The detailed process is as follows: (see FIG. 4)
TokenAB=Ra||Rb||sSa(Ra||Rb)
TokenBA=Rb||Ra||sSb(Rb||Ra)
1) The initiator B generates a random number Rb and sends the Rb to the responder A;
2) the responder A generates a random number Ra, signs Ra | Rb to form TokenAB, and sends the TokenAB to the initiator B;
3) the initiator B obtains the signature public key of the responder A from the white list of the trust list;
4) the initiator B verifies the signature information in the TokenAB to form TokenBA, and the TokenBA is sent to the responder A;
5) the responder A obtains a signature public key of the initiator B from a trust list white list;
6) responder a verifies the signature information in TokenBA.
And performing key agreement after login bidirectional authentication, wherein the key agreement generates and transmits the session key according to a related function in GMT 0018 cryptographic device application interface specification. The process is as follows:
1) the initiator B generates a random number R as a session key;
2) the initiator B obtains the encrypted public key of the responder A from the white list of the trust list;
3) the initiator B encrypts the random number R by using the encrypted public key of the responder A and sends the ciphertext value to the responder A;
4) the responder decrypts the random number R by using the encryption private key.
The above functions are all completed by the access control module.
The network protocol processing module completes the analysis and reconstruction functions of the protocol; the encryption and decryption module completes functions of encryption and decryption, integrity authentication and the like of service data, the encryption and decryption format of the service data adopts an ESP (encapsulating Security load) protocol format and an ESP tunnel mode, the ESP provides protection functions of confidentiality, data source authentication, data integrity, replay attack resisting service and the like, and a cipher grouping mode adopts a CBC mode.
ESP header format see FIG. 5
(1) Security parameter index SPI (32 bits): it identifies the security association of this data message together with the destination IP address and security protocol. The field is used for identifying which security policies are used by the sender when processing the IP data packet, and the receiver knows how to process the received packet after seeing the field;
(2) sequence number (32 bits): a monotonically increasing counter assigns a sequence number to each packet. When the two communicating parties establish a Security Association (SA), the initialization is 0. The SA is unidirectional, and the counter of the egress/ingress SA is incremented by 1 every time a packet is sent/received. This field may be used to resist replay attacks;
(3) load data: is a variable length field that contains the data described by the initialization vector IV and the next header field, which is in bytes in length. IV is located at the head of the payload data;
(4) filling data: if the length of the load data is not integral multiple of the packet length of the encryption algorithm, filling the insufficient part, wherein the filling takes bytes as a unit;
(5) filling length: the length of the padding is indicated in bytes, with a range of [0, 255 ]. The length of the encrypted data is guaranteed to adapt to the length of the block encryption algorithm. Where 0 represents no padding bytes;
(6) the next head: indicating the protocol immediately following the ESP header, which field is the value of the transport layer protocol under protection, such as 6 (TCP), 17 (UDP) or 50 (ESP);
(7) authentication data: the variable length field is an integrity check value ICV, which is a value obtained by carrying out integrity check calculation on the rest parts of the ESP message except the ICV. This field is only required if the authentication service is selected. The length of which is determined by the selected integrity check algorithm.
Position of ESP head
ESP Tunnel mode is shown in FIG. 6
Using the tunnel mode of ESP, ESP protects the entire original IP packet including the original inner IP header, as shown in fig. 6, where "data" includes "payload data" and "padding"; the "ESP trailer" contains "fill length" and "next header" fields.
1) Outbound message processing
The outbound message processing comprises the processes of searching SA, packaging, message encryption, serial number generation, integrity check value calculation, fragmentation and the like, and the outbound message processing is carried out according to the following sequence;
(1) and searching for SA: SA is looked up according to local policy, ESP is applied to an outbound packet only if an IPSec implementation determines that the packet is associated with the SA. Otherwise, a new key exchange process is started, and the SA is established;
(2) packaging: in the tunnel mode, the whole original value IP data message is encapsulated into an ESP load field;
(3) message encryption: firstly, adding all required padding to a message, and then encrypting by using a secret key, an encryption algorithm, an algorithm mode and an IV (fourth) specified by SA (security association), wherein the encryption range comprises load data, padding, a padding length and a next header;
(4) generating a sequence number: when an SA is established, the sender's creep good counter is initialized to 0, the counter is incremented by 1 before a message is not sent, and the counter is inserted into the sequence number field. When the counter reaches the maximum value, a new SA should be generated;
(5) and (3) calculating an integrity check value: the sender computes the ICV on the ESP message with the authentication data field removed. Assigning the calculated value to an authentication data field;
(6) slicing: after ESP processing, if the length of the IP data message is found to exceed the MTU value of the output interface, one IPSec fragments the processed data message.
2) Inbound message processing
The inbound message processing includes the processes of reassembly, SA lookup, serial number verification, integrity check value verification, message decryption, and reassembly, and is performed in the following order.
(1) And (3) recombination: if necessary, IP datagram reassembly is performed prior to ESP processing. The ESP does not process the fragment message, and if one message provided for ESP processing is a fragmented IP data message, the receiver should discard the message;
(2) and searching for SA: when a message containing an ESP header is received, a receiver searches for the SA according to a destination IP address, the ESP and the SPI, and if the search fails, the message is discarded;
(3) verifying the serial number: for each received message, the receiver should confirm that the message contains a sequence number, and the sequence number does not repeat the sequence numbers of any other received messages in the SA life cycle, otherwise, the message should be discarded;
(4) verifying the integrity check value: and the receiver calculates the ICV of the message by adopting a specified integrity check algorithm, and the calculated result is compared with the ICV value in the message. If the data messages are consistent, the received data messages are valid, otherwise, the receiving party discards the received data messages;
(5) message decryption: the encrypted portion of the received message is decrypted using the key, encryption algorithm, algorithm mode, and IV specified by the SA. And judging whether the decryption is successful according to the filling length and the filling data in the decrypted message. If the decryption fails, the message is discarded;
(6) and (3) reconstruction: and reconstructing the original IP data message for the message which is successfully decrypted.
The system for safely receiving and sending the terminal data of the Internet of things further comprises a key management module, wherein the key management module ensures the safety of the key:
1) the signature private key and the encryption private key of the terminal of the Internet of things are stored in the security chip, and only participate in operation in the security chip and cannot be exported;
2) the working key of the terminal of the Internet of things is generated by negotiation of an encryption key and an encryption key of a communication party, and does not appear in a communication link in a plaintext form.
The system for obtaining the safe data receiving and sending of the terminal of the Internet of things further comprises a log management module, wherein the log management module records the daily operation of the safety terminal and is mainly used for safety audit:
1) the safety terminal synchronously outputs detailed operation management log information and provides complete audit information;
2) and auditing operation log records of a system administrator and auditing access log records of a user are supported.
The above description is only for the purpose of describing the preferred embodiments of the present invention, and is not intended to limit the scope of the present invention, and any variations and modifications made by those skilled in the art based on the above disclosure are within the scope of the appended claims.

Claims (7)

1. The utility model provides a system that thing networking terminal data safety was received, was sent which characterized in that: the system comprises a network protocol processing module, an access control module and a data encryption and decryption module, wherein the network protocol processing module is responsible for analyzing and reconstructing a network protocol; the access control module controls the flow passing through the safety terminal, the flow of the system and the allowed service flow can pass through the Internet of things terminal, and unauthorized illegal flow and unknown flow cannot pass through the safety terminal; the data encryption and decryption module is responsible for encrypting and decrypting the service data passing through the terminal and carrying out integrity authentication, and if the integrity authentication fails, the data packet is discarded.
2. The system for safely receiving and sending the terminal data of the internet of things according to claim 1, is characterized in that: the access control module works in the following mode: the method comprises the steps that an Internet of things terminal is connected into a network, firstly, a security gateway of a server side is logged in, and key negotiation is carried out after login bidirectional authentication;
the protocol processing module completes the functions of analyzing and reconstructing the protocol; the encryption and decryption module completes the encryption and decryption and integrity identification functions of the service data, and the encryption and decryption format of the service data adopts an ESP protocol format and an ESP tunnel mode.
3. The system for safely receiving and sending the terminal data of the internet of things as claimed in claim 1 or 2, is characterized in that: the access control module controls the internet of things terminal to log in the security gateway of the server side, and the identity authentication process is as follows:
TokenAB=Ra||Rb||sSa(Ra||Rb)
TokenBA=Rb||Ra||sSb(Rb||Ra)
(1) the initiator B generates a random number Rb and sends the Rb to the responder A;
(2) the responder A generates a random number Ra, signs Ra | Rb to form TokenAB, and sends the TokenAB to the initiator B;
(3) the initiator B obtains the signature public key of the responder A from the white list of the trust list;
(4) the initiator B verifies the signature information in the TokenAB to form TokenBA, and the TokenBA is sent to the responder A;
(5) the responder A obtains a signature public key of the initiator B from a trust list white list;
(6) the responder A verifies the signature information in the TokenBA;
the access control module controls the internet of things terminal to perform key agreement, and the process comprises the following steps:
(1) the initiator B generates a random number R as a session key;
(2) the initiator B obtains the encrypted public key of the responder A from the white list of the trust list;
(3) the initiator B encrypts the random number R by using the encrypted public key of the responder A and sends the ciphertext value to the responder A;
(4) the responder decrypts the random number R by using the encryption private key.
4. The system for safely receiving and sending the terminal data of the internet of things according to claim 3, characterized in that: the ESP header format:
(1) security parameter index SPI (32 bits): it and IP address of purpose and security agreement have marked the security alliance of this data message together, used for marking the sender and using which security tactics while processing IP data packet, know how to process the packet received after the receiver analyzes this field;
(2) sequence number (32 bits): a monotonically increasing counter, which assigns a sequence number to each packet, when both communication parties establish a Security Association (SA), the sequence number is initialized to 0, the SA is unidirectional, the counter of the outgoing/incoming SA is increased by 1 every time a packet is sent/received, and the field can be used for resisting replay attack;
(3) load data: is a variable length field which contains the initialization vector IV and the data described by the next head field, the length unit is byte, the IV is positioned at the head of the load data;
(4) filling data: if the length of the load data is not integral multiple of the packet length of the encryption algorithm, filling the insufficient part, wherein the filling takes bytes as a unit;
(5) filling length: indicating the length of the padding item in the unit of byte, wherein the range is [0, 255], ensuring that the length of the encrypted data adapts to the length of the block encryption algorithm, and 0 represents no padding byte;
(6) the next head: indicating the protocol immediately following the ESP header, this field being the value of the transport layer protocol under protection;
(7) authentication data: the variable length field is an integrity check value ICV, and is a value obtained by carrying out integrity check calculation on the rest parts of the ESP message except the ICV, the field is required to be arranged only when verification service is selected, and the length of the field is determined by a selected integrity check algorithm.
5. The system for safely receiving and sending the terminal data of the internet of things according to claim 3, characterized in that: the position of the ESP head:
using the tunnel mode of the ESP, the ESP protects the whole original IP message including the original internal IP header;
(1) outbound message processing
The outbound message processing comprises the processes of searching SA, packaging, message encryption, generating sequence number, calculating integrity check value and fragmentation, and the like, and the outbound message processing is carried out according to the following sequence:
(1.1) search for SA: searching for SA according to local strategy, applying ESP to an outbound message only when one IPSec realizes that the message is associated with the SA, otherwise, starting a new key exchange process to establish SA;
(1.2) packaging: in the tunnel mode, the whole original value IP data message is encapsulated into an ESP load field;
(1.3) message encryption: firstly, adding all required padding to a message, and then encrypting by using a secret key, an encryption algorithm, an algorithm mode and an IV (fourth) specified by SA (security association), wherein the encryption range comprises load data, padding, a padding length and a next header;
(1.4) generating sequence number: when an SA is established, a slow good counter of a sender is initialized to be 0, the counter is added with 1 before a message is not sent, the counter is inserted into a serial number field, and a new SA is generated before the counter reaches the maximum value;
(1.5) calculating an integrity check value: the sender calculates ICV on ESP message without identification data field, and assigns the value obtained after calculation to the identification data field;
(1.6) fragmentation: after ESP processing is carried out by one IPSec, if the length of an IP data message is found to exceed the MTU value of an output interface, the processed data message is fragmented;
(2) inbound message processing
The processing of the inbound message comprises the processes of recombining, searching SA, verifying a serial number, verifying an integrity check value, decrypting the message, reconstructing and the like, and the processing is carried out according to the following sequence:
(1) and (3) recombination: if necessary, IP data message reassembly is carried out before ESP processing, the ESP does not process the fragment message, and if one message provided for ESP processing is the fragmented IP data message, a receiving party should discard the message;
(2) and searching for SA: when a message containing an ESP header is received, a receiver searches for the SA according to a destination IP address, the ESP and the SPI, and if the search fails, the message is discarded;
(3) verifying the serial number: for each received message, the receiver should confirm that the message contains a sequence number, and the sequence number does not repeat the sequence numbers of any other received messages in the SA life cycle, otherwise, the message should be discarded;
(4) verifying the integrity check value: the receiver adopts a specified integrity check algorithm to calculate the ICV of the message, the calculated result is compared with the ICV value in the message, if the calculated result is consistent with the ICV value in the message, the received data message is valid, otherwise, the receiver should discard the received data message;
(5) message decryption: decrypting the encrypted part of the received message by using a secret key, an encryption algorithm, an algorithm mode and an IV specified by the SA, judging whether the decryption is successful according to the filling length and the filling data in the decrypted message, and discarding the message if the decryption is failed;
(6) and (3) reconstruction: and reconstructing the original IP data message for the message which is successfully decrypted.
6. The system for safely receiving and sending the terminal data of the internet of things according to claim 1, characterized in that: the system for safely receiving and sending the terminal data of the Internet of things further comprises a key management module, wherein the key management module ensures the safety of the key:
1) the signature private key and the encryption private key of the terminal of the Internet of things are stored in the security chip, and only participate in operation in the security chip and cannot be exported;
2) the working key of the terminal of the Internet of things is generated by negotiation of an encryption key and an encryption key of a communication party, and does not appear in a communication link in a plaintext form.
7. The system for safely receiving and sending the terminal data of the internet of things according to claim 1, characterized in that: the system for safely receiving and sending the data of the terminal of the Internet of things further comprises a log management module, wherein the log management module records the daily operation of the terminal of the Internet of things and is used for safety audit:
1) the safety terminal synchronously outputs detailed operation management log information and provides complete audit information;
2) and auditing operation log records of a system administrator and auditing access log records of a user are supported.
CN202010116351.4A 2020-02-25 2020-02-25 System for safely receiving and sending terminal data of Internet of things Pending CN111245862A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010116351.4A CN111245862A (en) 2020-02-25 2020-02-25 System for safely receiving and sending terminal data of Internet of things

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010116351.4A CN111245862A (en) 2020-02-25 2020-02-25 System for safely receiving and sending terminal data of Internet of things

Publications (1)

Publication Number Publication Date
CN111245862A true CN111245862A (en) 2020-06-05

Family

ID=70876608

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010116351.4A Pending CN111245862A (en) 2020-02-25 2020-02-25 System for safely receiving and sending terminal data of Internet of things

Country Status (1)

Country Link
CN (1) CN111245862A (en)

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111741034A (en) * 2020-08-27 2020-10-02 北京安帝科技有限公司 Data transmission method, first terminal and second terminal
CN111935087A (en) * 2020-07-02 2020-11-13 上海微亿智造科技有限公司 Authentication verification method and system for gateway receiving large data volume through industrial internet
CN112333250A (en) * 2020-10-26 2021-02-05 天津市城市规划设计研究总院有限公司 Response method and system for Internet of things data packet in intelligent building
CN112733175A (en) * 2021-01-22 2021-04-30 浪潮思科网络科技有限公司 Data encryption method and device based on ESP (electronic stability program) protocol
CN113572766A (en) * 2021-07-23 2021-10-29 南方电网数字电网研究院有限公司 Power data transmission method and system
CN114142606A (en) * 2021-11-12 2022-03-04 株洲变流技术国家工程研究中心有限公司 Remote wireless communication method and system for rail transit energy scheduling
CN114157419A (en) * 2021-11-29 2022-03-08 军事科学院系统工程研究院网络信息研究所 OSPF-based secure routing protocol method and system
CN114244577A (en) * 2021-11-24 2022-03-25 贵州电网有限责任公司 Message processing method based on ESP
CN114301621A (en) * 2021-11-17 2022-04-08 北京智芯微电子科技有限公司 Intelligent substation and network communication safety control method and device thereof
CN114401130A (en) * 2022-01-06 2022-04-26 辽宁大学 Transmission method and system for all-cause failure immunity
CN114500013A (en) * 2022-01-13 2022-05-13 中国人民解放军海军工程大学 Data encryption transmission method
CN115242561A (en) * 2022-09-23 2022-10-25 中国电子科技集团公司第三十研究所 Method, device and medium for fragment processing after IPSec transmission mode overrun packet
CN115514712A (en) * 2021-06-22 2022-12-23 中移物联网有限公司 Data processing method, device, terminal and network side equipment
WO2023024540A1 (en) * 2021-08-24 2023-03-02 华为技术有限公司 Methods and apparatus for processing message and obtaining sa information, system, and medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104580233A (en) * 2015-01-16 2015-04-29 重庆邮电大学 Internet of Things smart home security gateway system
CN108881224A (en) * 2018-06-19 2018-11-23 南方电网科学研究院有限责任公司 A kind of encryption method and relevant apparatus of electrical power distribution automatization system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104580233A (en) * 2015-01-16 2015-04-29 重庆邮电大学 Internet of Things smart home security gateway system
CN108881224A (en) * 2018-06-19 2018-11-23 南方电网科学研究院有限责任公司 A kind of encryption method and relevant apparatus of electrical power distribution automatization system

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111935087A (en) * 2020-07-02 2020-11-13 上海微亿智造科技有限公司 Authentication verification method and system for gateway receiving large data volume through industrial internet
CN111935087B (en) * 2020-07-02 2021-04-06 上海微亿智造科技有限公司 Authentication verification method and system for gateway receiving large data volume through industrial internet
CN111741034B (en) * 2020-08-27 2020-12-22 北京安帝科技有限公司 Data transmission method, first terminal and second terminal
CN111741034A (en) * 2020-08-27 2020-10-02 北京安帝科技有限公司 Data transmission method, first terminal and second terminal
CN112333250B (en) * 2020-10-26 2022-03-01 天津市城市规划设计研究总院有限公司 Response method and system for Internet of things data packet in intelligent building
CN112333250A (en) * 2020-10-26 2021-02-05 天津市城市规划设计研究总院有限公司 Response method and system for Internet of things data packet in intelligent building
CN112733175A (en) * 2021-01-22 2021-04-30 浪潮思科网络科技有限公司 Data encryption method and device based on ESP (electronic stability program) protocol
CN115514712A (en) * 2021-06-22 2022-12-23 中移物联网有限公司 Data processing method, device, terminal and network side equipment
CN115514712B (en) * 2021-06-22 2023-09-05 中移物联网有限公司 Data processing method, device, terminal and network side equipment
CN113572766A (en) * 2021-07-23 2021-10-29 南方电网数字电网研究院有限公司 Power data transmission method and system
WO2023024540A1 (en) * 2021-08-24 2023-03-02 华为技术有限公司 Methods and apparatus for processing message and obtaining sa information, system, and medium
CN114142606A (en) * 2021-11-12 2022-03-04 株洲变流技术国家工程研究中心有限公司 Remote wireless communication method and system for rail transit energy scheduling
CN114301621A (en) * 2021-11-17 2022-04-08 北京智芯微电子科技有限公司 Intelligent substation and network communication safety control method and device thereof
CN114244577A (en) * 2021-11-24 2022-03-25 贵州电网有限责任公司 Message processing method based on ESP
CN114157419B (en) * 2021-11-29 2023-08-08 军事科学院系统工程研究院网络信息研究所 Security routing protocol method and system based on OSPF
CN114157419A (en) * 2021-11-29 2022-03-08 军事科学院系统工程研究院网络信息研究所 OSPF-based secure routing protocol method and system
CN114401130A (en) * 2022-01-06 2022-04-26 辽宁大学 Transmission method and system for all-cause failure immunity
CN114500013A (en) * 2022-01-13 2022-05-13 中国人民解放军海军工程大学 Data encryption transmission method
CN114500013B (en) * 2022-01-13 2023-06-13 中国人民解放军海军工程大学 Data encryption transmission method
CN115242561A (en) * 2022-09-23 2022-10-25 中国电子科技集团公司第三十研究所 Method, device and medium for fragment processing after IPSec transmission mode overrun packet
CN115242561B (en) * 2022-09-23 2023-01-31 中国电子科技集团公司第三十研究所 Method, device and medium for fragment processing after IPSec transmission mode overrun packet

Similar Documents

Publication Publication Date Title
CN111245862A (en) System for safely receiving and sending terminal data of Internet of things
CN109088870B (en) Method for safely accessing acquisition terminal of power generation unit of new energy plant station to platform
AlFardan et al. On the security of RC4 in TLS and WPA
CN106357690B (en) data transmission method, data sending device and data receiving device
JP2004295891A (en) Method for authenticating packet payload
US7636848B2 (en) Method, system, network and computer program product for securing administrative transactions over a network
CN112637136A (en) Encrypted communication method and system
CN113904809B (en) Communication method, device, electronic equipment and storage medium
CN101729871B (en) Method for safe cross-domain access to SIP video monitoring system
WO2012055204A1 (en) A management frame protection method and device based on wlan authentication and privacy infrastructure
CN113572766A (en) Power data transmission method and system
CN113904767A (en) System for establishing communication based on SSL
CN210839642U (en) Device for safely receiving and sending terminal data of Internet of things
Weis The use of rsa/sha-1 signatures within encapsulating security payload (esp) and authentication header (ah)
CN114614984B (en) Time-sensitive network secure communication method based on cryptographic algorithm
CN108111515B (en) End-to-end secure communication encryption method suitable for satellite communication
JP2004194196A (en) Packet communication authentication system, communication controller and communication terminal
CN115150076A (en) Encryption system and method based on quantum random number
CN112069487B (en) Intelligent equipment network communication safety implementation method based on Internet of things
Hayden et al. Multi-channel security through data fragmentation
Zuo et al. A novel software-defined network packet security tunnel forwarding mechanism
KR100381710B1 (en) Method For Security In Internet Server Based Upon Membership Operating System And Server Systems Regarding It
Barriga et al. Securing End-Node to Gateway Communication in LoRaWAN with a Lightweight Security Protocol
Limniotis et al. Cryptography threats
Wu et al. A high security framework for SMS

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