CN116599652A

CN116599652A - Safe communication method for distributed power supply power dispatching system

Info

Publication number: CN116599652A
Application number: CN202211735491.5A
Authority: CN
Inventors: 张晓�; 王友怀; 李伟; 何宇雄; 金石; 张雯露; 何智洪; 张光洲; 王春艳; 梁野; 宁志言; 王景; 邵立嵩; 张志军
Original assignee: Beijing Kedong Electric Power Control System Co Ltd; State Grid Hubei Electric Power Co Ltd
Current assignee: Beijing Kedong Electric Power Control System Co Ltd; State Grid Hubei Electric Power Co Ltd
Priority date: 2022-12-30
Filing date: 2022-12-30
Publication date: 2023-08-15

Abstract

The invention discloses a secure communication method for a distributed power supply dispatching system, comprising: controlling the client and the server to exchange and verify key information; calculating a shared key according to the exchanged key information, and responding to the key information The verification is successful; the handshake key and the application key are derived through the shared key; the encrypted tunnel between the client and the server is established through the handshake key; the authentication message interacted between the client and the server is transmitted through the encrypted tunnel; device ID and identity information, in response to the client or the server receiving the authentication message; when the client and the server pass the verification of the received authentication information, the application message exchanged between the client and the server is transmitted through an encrypted tunnel; the Authentication messages and application messages are encrypted with the application key; it can realize the port hiding ability and effectively avoid network attacks; it also has the characteristics of low resource consumption and low communication delay.

Description

Safe communication method for distributed power supply power dispatching system

Technical Field

The invention belongs to the technical field of safety communication, and particularly relates to a safety communication protocol for a distributed power supply power dispatching system.

Background

The clean low-carbon development is the subject of the energy development in the current world, and the development and application of clean energy such as distributed photovoltaic are effective means for solving the structural defects of oil and gas shortage in China. The scale of the distributed photovoltaic is rapidly increased, and the pressure of the distributed photovoltaic grid connection and local absorption is gradually increased, so that the absorption capacity of the distributed power supply such as the distributed photovoltaic is improved, and the regulation capacity of the power grid to the distributed power supply is enhanced, so that the important measure for ensuring the safe and stable operation of the power grid in the photovoltaic background of the whole county (city and district) is provided.

At present, aiming at large-scale grid connection of distributed photovoltaic power sources, a plurality of grid connection problems aiming at a distributed power source power dispatching system are solved; however, the technical problem of how to safely transmit information between the distributed power generation terminal and the power dispatching system still exists in the prior art;

the common communication protocols between the power generation terminal and the power dispatching system comprise secure socket layer security (SSL), transport Layer Security (TLS) and IPSec protocols for information transfer; the IPSec protocol requires a large amount of system resource support, each connection needs to maintain two security associations, when a key is replaced, 4 security associations need to be maintained, and the system resource consumption is large and is not suitable for a distributed power source scene; both SSL and TLS protocols are based on TCP protocols, which, according to their specifications, must respond to a request packet, thus resulting in a failure to hide the device and a tendency to cause DDos attacks; therefore, the social industry production is urgently required to a safe communication method for the distributed power supply power dispatching system, which is used for solving the technical problem of how to safely transmit information between the distributed power supply power generation testing terminal and the power dispatching system.

Disclosure of Invention

The invention aims to provide a safe communication method for a distributed power supply power dispatching system, which is based on UDP protocol, can realize port hiding capability and effectively avoid network attack; meanwhile, the method has the characteristics of low resource consumption and low communication time delay.

In order to achieve the above purpose, the technical scheme adopted by the invention is as follows:

the first aspect of the present invention provides a secure communication method for a distributed power supply power dispatching system, including:

controlling the client and the server to exchange and verify key information; calculating a shared key according to the exchanged key information, and responding to successful verification of the key information;

deriving a bill key, a handshake key and an application key through the shared key; establishing an encryption tunnel between the client and the server through a handshake key;

transmitting an authentication message interacted between the client and the server through an encryption tunnel; verifying the device ID and the identity information in the authentication message, and responding to the client or the server receiving the authentication message;

after the authentication information received by the client and the server passes verification, transmitting an interactive application message between the client and the server through an encryption tunnel; the authentication message and the application message are encrypted using an application key.

Preferably, the method of controlling the client and the server to exchange and verify key information with each other includes:

sending a handshake message of a ClientHello type to a server through a client; the handshake message of the ClientHello type comprises cipher suite type and key sharing information supported by the client;

checking cipher suite type and KeyShare key sharing information in the handshake message of the ClientHello type, and responding to the server to receive the handshake message of the ClientHello type;

if the types of the cipher suite supported by the server and the client are not matched, sending a cipher suite error type alarm message to the client;

if the server is matched with the password suite type supported by the client, and the server is compatible with the Group parameter in the Key share information, the server passes verification, and a handshake message of ServerHello type is sent to the client;

if the server is matched with the type of the cipher suite supported by the client, the server is not compatible with the ECC algorithm group in the Key shared secret key sharing information; sending a Hello Retry Request type handshake message to the client; the Hello Retry Request type handshake message comprises a server-selected cipher suite type and a server-supported ECC algorithm group;

In response to the client receiving a Hello Retry Request type handshake message, judging whether the client supports an ECC algorithm group in the Hello Retry Request type handshake message; when the client supports the ECC algorithm group in the Hello Retry Request type handshake message, updating the ClientHello type handshake message according to the ECC algorithm group in the Hello Retry Request type handshake message and flushing and sending the updated ClientHello type handshake message to the server;

and when the client does not support the ECC algorithm group in the Hello Retry Request type handshake message, sending parameter error type alarm information to the server.

Preferably, the method for deriving the handshake key and the application key by the shared key comprises:

and carrying out 16-ary addition according to the shared key, the Random parameter of the ServerHello type handshake message and the Random parameter of the ClientHello type handshake message to obtain a basic key, wherein the expression formula is as follows:

BaseKey＝hex(ClientHello.Random)+hex(ServerHello.Random)

+hex(ECDH.PublicKey)

in the formula, baseKey is expressed as a base key; the ClientHello. Random is expressed as a Random parameter of a ClientHello-type handshake message; random is expressed as a Random parameter of a ServerHello type handshake message; hex is expressed as a 16-ary conversion operation;

the handshake key and the application key are derived from the base key using the hkey algorithm.

Preferably, the method for establishing the encryption tunnel between the client and the server through the handshake key comprises the following steps:

sending Finish type handshake messages between the client and the server, wherein a HandshakeData part of the Finish type handshake messages is encrypted through a HandshakeKey;

checking whether transmission hash values in Finish type handshake messages sent by a client and a server are matched or not; if the transmission hash value in the Finish type handshake message is matched, the establishment of an encryption tunnel between the client and the server is completed; otherwise, the client sends HashError type alarm information to the server.

Preferably, after the client and the server mutually send Finish type handshake messages, the client and the server mutually send NewSessionTicket type handshake messages; the handshake message of the NewSessionTicket type comprises bill survival time, bill survival time confusion parameters, bill identification and bill type; the pre-shared key information is generated or updated according to a handshake message of the NewSessionTicket type.

Preferably, when the session between the client and the server is ended and the client re-initiates the session, the client sends a ClientHello type handshake message containing the pre-shared key information generated by the client to the server; after receiving the handshake message of the ClientHello type, the server checks the preshared key information; if the pre-shared key information is checked to pass, a Finish type handshake message is mutually sent between the client and the server; if the pre-shared key information checking is not passed, a HelloRetryRequest type handshake message is sent to the client.

Preferably, the method for verifying the device ID and the identity information in the authentication message by encrypting the authentication message interacted between the tunneling client and the server comprises:

the client sends an authentication message containing the device ID and identity information of the client to the server;

after receiving the authentication information sent by the client, the server extracts the equipment ID and the identity information in the authentication information sent by the client, repackages the equipment ID and the identity information to obtain an encapsulation message, and forwards the encapsulation message to an external authentication server;

the external authentication server authenticates the client according to the encapsulation message and feeds back an authentication result to the server;

and the server sends an authentication message to the client according to the authentication result fed back by the external authentication server.

If the verification failure times of the authentication message sent by the client exceeds a set threshold, the server lists the client which fails to verify in a blacklist; when the server receives the authentication message sent by the client in the blacklist, the server directly responds to the authentication message of refusing to access the AVP.

Preferably, the method for the server to send the authentication message to the client according to the authentication result fed back by the external authentication server includes:

When the external authentication server response time exceeds the set time threshold a, the server sends an authentication message containing the remote authentication server timeout type AVP and the authentication failure type AVP to the client.

When the authentication result is that the authentication information sent by the client passes the verification, the server sends an authentication information containing the equipment ID, the equipment type AVP, the authentication type AVP and authentication success of the server to the client;

and when the authentication result is that the authentication information sent by the client fails to pass the authentication, the server sends an authentication information containing identity errors, authentication errors and authentication failure AVP to the client.

Preferably, when the time of the data not transmitted between the client and the server exceeds a set time threshold B, heartbeat packets are mutually transmitted between the client and the server; and responding with a heartbeat packet when the client or the server receives the heartbeat packet, otherwise, the client or the server is taken off line.

Preferably, when the client side needs to update the application key, generating a 256-bit random number, and generating a new application key by using the random number; the client fills the Random number into a Key-Update-Random attribute of a Key Update type handshake message, and sends the Key Update type handshake message to the opposite terminal;

Or when the server side needs to update the application key, generating a 256-bit random number, and generating a new application key by using the random number; the server fills the Random number into the Key-Update-Random attribute of the Key Update type handshake message, and sends the Key Update type handshake message to the opposite terminal;

after receiving the handshake message of the KeyUpdate type, the client or the server updates the application Key through the KeyUpdate-Random attribute in the handshake message of the KeyUpdate type.

Preferably, the handshake message, the authentication message, the alarm message and the application message are DSTP datagrams; the DSTP header format of the DSTP datagram includes Type, flag feature, msg message, identifier and Length: the Type is used for identifying the datagram Type of the DSTP datagram; the Flag feature is used for identifying the fragmentation information in the DSTP datagram; msg message identifies the message type of the DSTP datagram; the Identifier is used for identifying the uniqueness of the DSTP datagram; the Length is used to identify the total Length of the DSTP datagram.

Preferably, the DSTP datagram is preceded by an ethernet header, an IP header and a UDP header.

Preferably, the Flag features comprise an Lbit and an Mbit; the Lbit setting identifies that the DSTP message contains a length field of 4 bytes; mbit sets fragmentation information for identifying DSTP datagrams; when the Lbit of the Flag feature is set to 1, the DSTP header format of the DSTP datagram further comprises a DataLength data length; the DataLength data length is used to identify the total length of data that needs to be fragmented.

Preferably, when the application Data transmitted between the client and the server is greater than a set transmission threshold, setting Mbit and Lbit of the Flag field of the DSTP datagram to be 1, and filling the application Data size into the Data Length field of the DSTP datagram;

performing data cutting on application data according to the maximum transmission unit; packaging the cut application data into DSTPRequest fragment datagrams and sending the DSTPRequest fragment datagrams to a client or a server;

after receiving the DSTPRequest fragment datagram, extracting application Data in the DSTPRequest fragment datagram for recombination, comparing the application Data with a Data Length field, and if the application Data are equal in Length, successfully transmitting the Data; if not, the transmission fails.

Preferably, the Identity field of each DSTPRequest fragment datagram is calculated to obtain sumresponse id, and after the client or the server serving as the sender finishes sending the DSTPRequest fragment datagram;

calculating an Identity field in the received DSTPRequest fragment datagram to obtain a SumACKID, and responding to a client or a server serving as a receiver to receive the DSTPRequest fragment datagram;

checking whether the SumResponseID is equal to the SumACKID in the ACK message, and if so, considering that the application message is sent correctly; otherwise, resend the DSTPRequest fragment datagram.

Compared with the prior art, the invention has the beneficial effects that:

the invention increases the confirmation mechanism on the basis of UDP protocol, improves the reliability of DSTP; a data slicing mechanism is added, and the transmission capacity of a large-volume data block is provided for upper application data; the heartbeat maintaining capability is increased, and the reliability of long connection between clients and servers can be effectively ensured.

The data transmitted between the client and the server are encrypted, and the randomness of the key generation is increased by using a random number mechanism; different keys are derived for various types of data by using a KDCH function, so that the difficulty of data decryption is increased, and the application data is prevented from being decrypted due to the fact that the keys are lost at a certain stage.

Drawings

FIG. 1 is a flow chart of a secure communication method for a distributed power source power dispatching system provided by the invention;

FIG. 2 is a flow chart of a secure communication method for a distributed power source power dispatching system provided by the invention;

FIG. 3 is a diagram of the relationship between DSTP datagrams and UDP datagrams and application data provided by the present invention;

FIG. 4 is a diagram of a shared key relationship provided by the present invention

FIG. 5 is a flow chart of a first phase interaction of a client and a server provided by the present invention;

FIG. 6 is a flow chart of a second phase interaction of a client and a server provided by the present invention;

FIG. 7 is a flow chart of a third phase interaction of a client and a server provided by the present invention;

fig. 8 is a flowchart of DSTP fragment transmission provided by the present invention;

fig. 9 is a flowchart of a DSTP fragment datagram reliability guarantee mechanism provided by the present invention;

FIG. 10 is a diagram of a Client Hello message format provided by the present invention;

fig. 11 is a diagram of AVP field format provided by the present invention.

Detailed Description

The invention is further described below with reference to the accompanying drawings. The following examples are only for more clearly illustrating the technical aspects of the present invention, and are not intended to limit the scope of the present invention.

As shown in fig. 1 to 9, the present embodiment provides a secure communication method for a distributed power supply power scheduling system, which is applied to an OSI network model; the OSI network model refers to: the open system interconnection communication reference model (English: open System Interconnection Reference Model, abbreviated OSI), abbreviated OSI model (OSI); the OSI model includes (from low to high): the present invention works between a physical layer, a data link layer, a network layer, a transport layer (TCP/UDP) and an application layer.

As shown in fig. 2, messages are interactively transmitted between the server and the client through the OSI network model; the transmission information consists of a data link datagram, an IP datagram, a TCP/UDP datagram and a DSTP datagram; an Ethernet header, an IP header and a UDP header are arranged in front of the DSTP datagram;

when the DSTP datagram is used as a Request datagram, the DSTP header format of the DSTP datagram includes a Type, flag characteristics, msg message, identifier, and Length:

type, length 4bit, the datagram Type of the DSTP datagram is marked, the value is 1,2 (10 system), and the method specifically comprises the following steps:

1=request (Request)

2=ack (acknowledgement)

Flag feature: the length is 8 bits, the information such as the datagram fragments is marked, the Flag features comprise Lbit, mbit and Rbit, and the contents of the Flag fields are as follows:

L

M

R

wherein each bit from left to right has the meaning: l=length included contains a Length field; m=more fragments fragment identity; r=reserved field; the Lbit setting identifies that the DSTP message contains a length field of 4 bytes; mbit settings identify fragmentation information for DSTP datagrams.

Msg message: the length is 4bit, the message type of the DSTP message is marked, the value is 1-5 (10 scale system), and the message type is specifically: 1=handshake message, 2=authentication message, 3=data message, 4=alert message, 5=application message;

Identifier identification: length 24 bits, which is used to identify the uniqueness of the DSTP datagram, the Identifier identification field of the reply datagram (ACK) must have the same value as the Identifier identification field of its corresponding Request datagram (Request). The field is divided into 2 parts, the first 8 bits are marked with a value of 0-255; the last 16 bits are randomly generated numbers with values of 1-65535.

Length: length 24 bits, identifying the total length of the DSTP datagram.

DataLength data length: when the Lbit of the Flag feature is set to 1, the DSTP header format of the DSTP datagram further comprises a DataLength data length; the DataLength data length is used to identify the total length of data that needs to be fragmented.

When a DSTP datagram is used as a DSTP ACK (acknowledgement) datagram, the DSTP ACK (acknowledgement) datagram format is the same as the Request datagram format, and the datagram header content must be the same as the Request datagram corresponding thereto.

DSTP ACK (acknowledgement) datagram application data field is set to 0 xFFFFFFFFFFFFFFFFFF

When a DSTP ACK (acknowledgement) datagram is an acknowledgement message of a packet datagram, the M bit of the Flag field of the datagram is set to 1.

The types of the DSTP datagrams include the handshake message, authentication message, alarm message and application message;

The HandShake message consists of two parts, a HandShake Type and a HandShake data; handleshakedata (handshake data): the specific content of the handshake message; handshaketype (HandShake Type): length 8bit, identifies the specific handshake type of the message, specific reference is (10 system): 1=client Hello message, 2=serverhello message, 3=heloretryrequest message, 4=key Update message, 5=newsessionticket message, 200=finished message

1) ClientHello message

When a Client connects to a Server for the first time, it needs to send a ClientHello as the first message. When a Server responds to ClientHello of a Client with a HelloRetryRequest, the Client should also send ClientHello. The Client Hello message is composed of Random, cipherersuite List and at least one Attribute 3 part; the Client Hello message format is shown in fig. 10:

wherein Random (Random number): the length is 32Byte, the random number generated by the random number generator at the Client end is used for calculating the shared secret key; ciphered suite List: the length is not fixed, and the field consists of a CipgerSuite ListLength (cipher suite list length) field and at least one ciphersite field; cipgerSuite ListLength (cipher suite list length): length 16 bits, identifying the overall length of the field; cipbersuite: length 16 bits, is a specific cipher suite content.

Attribute (Attribute): the Length is not fixed, and the field consists of three fields, namely an Att-Type field, an Att-Length field and an Att-Data field;

Att-Type (attribute Type): length 8 bits, identifying the type of the attribute. Specific values are (10 scale):

1=group, ECC elliptic curve arithmetic Group, optional value 0x0017 (secp 256r 1), 0x0018 (secp 384r 1), 0x0019 (secp 521r 1), 0x001D (x 25519), 0x001E (x 448)

2=key-Share (shared Key), the ECDH algorithm requires exchanged information.

3=pre-Share-Key (Pre-shared Key), key information shared between Client and Server (Server), mainly for session reply.

Att-Length (attribute Length): length 16 bits, identifying the overall length of the attribute field.

Att-Data (attribute Data): the length is not fixed, identifying the specific content of the type attribute. The method comprises the following steps:

group (Group): this type of Att-Data contains at least one Group field of length 32 bits that identifies the set of ECC elliptic curve algorithms supported by the sender.

Key-Share (shared Key): the Att-Data (attribute Data) of this type includes a Group field of 32 bits in length and a Key-Exchange field of unfixed length, wherein the Group field identifies the ECC elliptic curve algorithm Group selected by the sender and the Key-Exchange identifies the public Key information to be exchanged.

Pre-Share-Key: this type consists of a ObfuscatedTicaket Age (obfuscated ticket generation time) field of 64 bits in length and a Pre-Share-Key (Pre-shared Key) field of 256 bits in length, obfuscatedTicaket Age (obfuscated ticket generation time) field identifying the lifetime of the Pre-Share-Key, the Pre-Share-Key field identifying the specific contents of the Pre-Share-Key.

2) ServerHello message

When an acceptable set of handshake parameters can be negotiated according to ClientHello, the Server will send this message in response to the ClientHello message to continue the handshake procedure. The ServerHello message consists of Random, ciphered suite, and an Attribute 3 part.

3) HelloRetryRequest message

If an acceptable set of parameters can be found, but there is insufficient information in the ClientHello to continue processing the handshake flow, the Server responds with a HelloRetryRequest message. The message format and field definition of the HelloRetryRequest message are the same as ServerHello.

4) Key Update message

When the Key needs to be updated, the Client or the Server sends a Key Update message to the other party, wherein the message comprises a Key-Update-Random field with the length of 256 bits;

5) Finished message

After the handshake process of stage 1 is completed between Client and Server, finish message is sent, which is mainly composed of a TransportHash field;

TransportHash (transport Hash): the length is 256 bits, and the sum of all message hash values sent by Client or Server is identified.

6) NewSessionTicket message

7) The newsessiontime message is sent after the Finish message and is used for transmitting PSK (pre-shared key) related information, and the message consists of a time-LifeTime (Ticket LifeTime), a time-Obfuscate-LifeTime (Ticket LifeTime confusion parameter), a time-Identity (Ticket identifier) and a time-Type (Ticket Type) 4 part.

The authentication message comprises an AVP (Attribute-Value Pair) field, and in order to ensure the compatibility of external authentication, the definition and field format of the AVP in the patent are the same as RFC 3588Diameter Based Protocol; AVP (Attribute-Value Pair): the AVP field carries specific information required for authentication, and is composed of AVP Code, AVP Flag, AVPLength, AVPData 4 parts, and the AVP field format is shown in fig. 11.

AVP Code (AVP Code): the length 32bit, identifies the AVP type, and AVP used in this document is identified as 5000, which is a private identification that is not registered in the IANA.

AVP Flag (AVP identification): length 8bit, identify AVP field related attributes, AVP Flag field format is:

V

M

P

R

the Vbit identifies the Vendor ID attribute, and when this bit is set to 1, the Vendor-ID field should be included in the AVP field. The M bit field is a mandatory field and when this bit is set to 1, the authentication proxy, authentication server must support this AVP. Pbit identifies a protection attribute that should provide end-to-end encryption protection when this bit is set to 1. Rbit is reserved bit and needs to be set to 0.

Avplenth (AVP length): length 24 bits, identifying the total length of this AVP field

vender-ID (Vendor ID): an optional field identifying vendor information sent by the authentication message, the optional field only being present when Vbit of AVP Flag is 1;

AVPData (AVP data): this field consists of AVPValue (AVP value) and Data fields;

AVP Value (AVP Value): length 16 bits, which corresponds to the AVP Code field, indicating the subtype under the Code type. The values are 1-9, 253 and 254.

1=deviceidentity (device identity)

2=authtype-Password (authentication type-Password)

3=authtype-Certificate

4=authtype-Signature (authentication type-Signature)

5 = Error-identity Error

6=error-authentication Error (authentication Error)

7=error-remottauthservertimeout (remote authentication server timeout)

8 = Error-Unexpected-Msg (Unexpected information)

9=Access-Deny (Access denied)

253 AuthSucess (authentication success)

254 AuthFail (authentication failure)

AVP Data (AVP Data): the particular contents of the AVP field. The AVP Data (AVP Data) of each type of AVP is specifically as follows:

DeviceIdentity: hash value with length of 256 bits

AuthType-Password: plaintext password for authentication

AuthType-Certificate: identity certificate for identity verification

AuthType-Signature: data signature for identity verification

Error-identity Error: has a value of 0xFFFFFFFF

Error-authentication Error of 0xFFFFFF

Error-RemotAuthServerTimeout (remote authentication Server timeout): value 0xFFFFFFFF

Error-Unexpeted-Msg (Unexpected information) value of 0xFFFFFFFF

Access-Deny (denial of Access) value 0xFFFFFFFF

AuthSucess (authentication success) value 0xFFFFFFFF

AuthFail (authentication failure) value 0xFFFFFFFF.

The warning message is composed of an Alert-Type and an Alert-Msg;

Alert-Type: the length is 8bit, the type of the alarm is marked, the value is 1-4, and the method specifically comprises the following steps:

1=cipherersuitererror (cipher suite error)

2=parametererror (parameter error)

3=pskerror (PSK error)

4=unknowpacket (unknown packet)

5=hasherror (check error)

Alert-Msg (Alert information): the specific content of the identification alert may be null.

In order to ensure the transmission reliability of the DSTP message, when the DSTP message receiver does not need to return information, a DSTP response message needs to be returned, the Type value of the message is 2, the flag field is 0b00000000, the msg value is 5, the Identifier is the same as the Identifier in the Request, the Length value is 72, and the appdata field value is 0xFFFF;

the invention is realized by depending on the scheme belonging to the UDP protocol, has the advantages of UDP protocol, such as supporting multiple users, fast speed, low time delay and the like, and simultaneously compensates the disadvantages of UDP protocol by DSTP protocol: the confirmation mechanism is added, so that the reliability of DSTP is improved; a data slicing mechanism is added, and the transmission capacity of a large-volume data block is provided for upper application data; the heartbeat maintaining capability is increased, and the reliability of long connection between clients and servers can be effectively ensured.

A safe communication method for a distributed power supply power dispatching system comprises the following specific processes:

the first stage of exchanging key information and establishing an encryption tunnel includes:

And calculating a shared key according to the exchanged key information, and responding to successful verification of the key information.

The method for deriving the bill key, the handshake key and the application key through the shared key comprises the following steps:

BaseKey＝hex(ClientHello.Random)+hex(ServerHello.Random)+hex(ECDH.PublicKey)

Pushing out a bill key, a handshake key and an application key from the basic key by using an HKEF algorithm; the ticket key is used to generate a pre-shared key.

The method for establishing the encryption tunnel between the client and the server through the handshake key comprises the following steps:

After the client and the server mutually send Finish type handshake messages, the client and the server mutually send NewSessionTicket type handshake messages; the handshake message of the NewSessionTicket type comprises bill survival time, bill survival time confusion parameters, bill identification and bill type; the pre-shared key information is generated or updated according to a handshake message of the NewSessionTicket type.

And in the second stage, transmitting the respective identity information through an encryption tunnel, and verifying the identity information of the opposite terminal to ensure that the opposite terminal is legal equipment, wherein the method comprises the following steps:

transmitting an authentication message interacted between the client and the server through an encryption tunnel; verifying the device ID and the identity information in the authentication message, and responding to the client or the server receiving the authentication message; the specific method comprises the following steps:

The method for the server to send the authentication message to the client according to the authentication result fed back by the external authentication server comprises the following steps:

According to the embodiment, aiming at the characteristics of the distributed power supply service, a third party authentication mode is designed and supported, the Server can forward authentication information to an external authentication Server for centralized authentication, the distributed access-centralized authentication mode can be realized in this way, the processing performance of the Server can be effectively improved, and meanwhile, the centralized management mode can effectively manage the identity information of the distributed power supply terminal.

The third stage of the method for transmitting the application information through the encrypted tunnel comprises the following steps:

When the application Data transmitted between the client and the server is larger than a set transmission threshold, setting Mbit and Lbit of the Flag field of the DSTP datagram to be 1, and filling the Data Length field of the DSTP datagram with the application Data size;

Calculating the Identity field of each sent DSTPRequest fragment datagram to obtain SumResponseID, and responding to a client or a server serving as a sender to send the DSTPRequest fragment datagram;

When the session between the client and the server is ended and the client re-initiates the session, the client sends a ClientHello type handshake message containing pre-shared key information generated by the client to the server; after receiving the handshake message of the ClientHello type, the server checks the preshared key information; if the pre-shared key information is checked to pass, a Finish type handshake message is mutually sent between the client and the server; if the pre-shared key information checking is not passed, a HelloRetryRequest type handshake message is sent to the client.

When the time of data transmission between the client and the server exceeds a set time threshold B, heartbeat packets are mutually sent between the client and the server; and responding with a heartbeat packet when the client or the server receives the heartbeat packet, otherwise, the client or the server is taken off line.

When the client side needs to update the application key, generating a 256-bit random number, and generating a new application key by using the random number; the client fills the Random number into a Key-Update-Random attribute of a Key Update type handshake message, and sends the Key Update type handshake message to the opposite terminal;

All authentication data and application data transmission are encrypted, and the randomness of key generation is increased by using a random number mechanism; different keys are derived for various types of data by using a KDCH function, so that the difficulty of data decryption is increased, and the application data is prevented from being decrypted due to the fact that the keys are lost at a certain stage; providing use and Key updating capability for an Application Key (Application Key), and periodically updating the Application Key (Application Key); application keys (Application keys) have forward security, and even if Application keys (Application keys) at the current stage are obtained, the last Application Key (Application Key) cannot be pushed out reversely.

It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The foregoing is merely a preferred embodiment of the present invention, and it should be noted that modifications and variations could be made by those skilled in the art without departing from the technical principles of the present invention, and such modifications and variations should also be regarded as being within the scope of the invention.

Claims

1. A secure communication method for a distributed power supply power dispatching system, comprising:

deriving a handshake key and an application key from the shared key; establishing an encryption tunnel between the client and the server through a handshake key;

2. The secure communication method for a distributed power scheduling system according to claim 1, wherein the method of controlling the client and the server to exchange and verify the key information with each other comprises:

3. A method of secure communication for a distributed power supply power dispatching system as recited in claim 2, wherein deriving the handshake key and the application key from the shared key comprises:

BaseKey＝hex(ClientHello.Random)+hex(ServerHello.Random)

+hex(ECDH.PublicKey)

in the formula, baseKey is expressed as a base key; the ClientHello. Random is expressed as a Random parameter of a ClientHello-type handshake message; random is expressed as a Random parameter of a ServerHello type handshake message; hex (·) is represented as a 16-ary conversion operation;

4. A method of secure communication for a distributed power scheduling system according to claim 3, wherein the method of establishing an encrypted tunnel between a client and a server by means of a handshake key comprises:

5. The method for secure communication of a distributed power supply power scheduling system according to claim 4, wherein after a Finish type handshake message is sent between the client and the server, a NewSessionTicket type handshake message is sent between the client and the server; the handshake message of the NewSessionTicket type comprises bill survival time, bill survival time confusion parameters, bill identification and bill type; the pre-shared key information is generated or updated according to a handshake message of the NewSessionTicket type.

6. The secure communication method for a distributed power supply power scheduling system according to claim 1, wherein when a session between a client and a server is ended and the client re-initiates the session, the client sends a ClientHello-type handshake message containing pre-shared key information generated by the client to the server; after receiving the handshake message of the ClientHello type, the server checks the preshared key information; if the pre-shared key information is checked to pass, a Finish type handshake message is mutually sent between the client and the server; if the pre-shared key information checking is not passed, a HelloRetryRequest type handshake message is sent to the client.

7. The method for secure communication for a distributed power dispatching system of claim 1, wherein the method for verifying the device ID and identity information in the authentication message by encrypting the authentication message interacted between the tunneled client and the server comprises:

8. The method for secure communication for a distributed power supply power dispatching system according to claim 7, wherein the method for sending the authentication message to the client by the server according to the authentication result fed back by the external authentication server comprises:

9. The method for secure communication of a distributed power supply power scheduling system according to claim 1, wherein when the time of data transmission between the client and the server exceeds a set time threshold B, heartbeat packets are mutually transmitted between the client and the server; and responding with a heartbeat packet when the client or the server receives the heartbeat packet, otherwise, the client or the server is taken off line.

10. The secure communication method for a distributed power supply power scheduling system according to claim 1, wherein when application Data transmitted between a client and a server is greater than a set transmission threshold, mbit and Lbit of Flag fields of a DSTP datagram are set to 1, and Data Length fields of the DSTP datagram are filled with application Data size;

after receiving the DSTPRequest fragment datagram, extracting application Data in the DSTPRequest fragment datagram for recombination, comparing the application Data with a Data Length field, and if the application Data are equal in Length, successfully transmitting the Data; if the lengths are not equal, the transmission fails.