A secure communication method based on distributed BACnet devices

Abstract

The application belongs to the technical field of data network communication security, and particularly relates to a secure communication method based on distributed BACnet equipment.The application comprises the following steps: sending a request authentication message with a certificate to a group;generating a certificate for an applicant and signing and returning a certificate message by an equipment in the group, so as to complete authentication; when communication is needed, sending a request connection request to equipment B by equipment A; after receiving the request, equipment B carries out security authentication, and if the authentication fails, equipment B returns a connection rejection message, and equipment A receives the message and re-authenticates in the group; if the authentication succeeds, equipment B sends a request connection request with check information; equipment A receives and verifies the security of equipment B, and then uses an SM2 algorithm to encrypt a randomly generated pre-master key according to the public key of equipment B, and sends the pre-master key to equipment B; equipment A uses a communication master key to encrypt a secure connection message and sends the secure connection message to equipment B, and equipment B completes decryption verification and scheduling number, so as to complete encryption negotiation.The application has high security and is compatible with the BACnet protocol.

Description

Technical Field

[0001] This invention belongs to the field of data network communication security technology, specifically relating to a secure communication method based on distributed BACnet devices. Background Technology

[0002] BACnet is an object-oriented, peer-to-peer network protocol that adopts a simplified OSI-RM architecture to ensure communication efficiency. It defines four layers: application layer, network layer, data link layer, and physical layer. BACnet focuses on the network layer and above, and its goal is to run on any data link and physical medium.

[0003] Currently, commercial cryptographic algorithms mainly fall into three categories: SM2 elliptic curve public key cryptography [1], SM3 hash algorithm [2], and SM4 block cipher algorithm [3]. SM2 elliptic curve public key cryptography is used for asymmetric encryption, SM3 hash algorithm is suitable for digital signatures, and SM4 block cipher algorithm is suitable for data encryption and decryption.

[0004] Deploying distributed systems is a major trend in the development of various systems. Distributed systems eliminate the need for a central node, facilitating initial commercial deployment and subsequent system expansion; they also enhance system security through distributed mechanisms. Distributed systems are an excellent solution for modern systems. Summary of the Invention

[0005] The purpose of this invention is to provide a secure communication method for BACnet devices that is highly secure and compatible with the BACnet protocol.

[0006] This invention utilizes a distributed approach to complete authentication and secure device communication based on the BACnet protocol.

[0007] This invention provides a secure communication method based on distributed BACnet devices. The method involves sending a certificate-bearing authentication request message to a group; devices within the group generate and sign certificates for applicants, returning a certificate message to complete authentication; when communication is needed, device A sends a connection request message to device B; device B, upon receiving the request, performs security authentication. If authentication fails, device B returns a connection rejection message, which device A then re-authenticates within the group; if authentication succeeds, device B sends a connection request message with verification information; device A receives and verifies device B's security, then encrypts a randomly generated pre-master key using the SM2 elliptic curve public-key cryptography algorithm based on device B's public key, and sends it to device B; device A then encrypts a secure connection message using the negotiated communication master key and sends it to device B; device B decrypts and verifies the Invoke ID, thus completing the encryption negotiation.

[0008] The specific steps are as follows:

[0009] Step 1: System initialization. Devices connected to the system use the SM2 elliptic curve public key cryptography algorithm to generate their own public key P and private key K, and send a request for authentication message to the group to which the devices belong to apply for authentication.

[0010] Step 2: After receiving the message, the devices in the group generate and sign a certificate for the applicant and return a certificate message.

[0011] Step 3: The requesting party saves the public key and generates a new signing certificate based on the received certificate message;

[0012] Step 4: Device A sends a connection request message to Device B with a sequence number of 0;

[0013] Step 5: After receiving the request, device B verifies the signature SIGa and saves the random number RANa. After confirming the security of A, it generates a random number DEV, encrypts DEV using the public key in device A's certificate CERa using the SM2 elliptic curve public key cryptography algorithm to obtain an encrypted value, and returns a connection request message with the encrypted value and a sequence number of 1. If it fails, it returns a connection rejection message, and device A needs to apply for a certificate again and initiate a connection request.

[0014] Step 6: After receiving the connection request message, Device A verifies the security of Device B using the same method, saves the random number RANb, and decrypts the encrypted value ENV using its own private key to obtain the random number DEV. If secure, Device A uses the public key in the certificate CERb to encrypt the randomly generated pre-master key PMK using the SM2 elliptic curve public key cryptography algorithm, sends a secure connection message to Device B, and sets the Invoke ID to DEV and the sequence number to 2.

[0015] Step 7: Device B uses its private key to decrypt the 8-byte pre-master key PMK and compares the random number DEV in the InvokeID with the previously set random number to ensure the security of this negotiation. At this point, both devices have obtained the negotiated communication master key MK = RANa||RANb||PMK. To verify the feasibility of communication, Device B uses the communication key to encrypt an encryption option IsKey (not specified), which contains a secure connection message that uses the communication master key to encrypt the random number DEV using the SM4 block cipher algorithm, with a sequence number of 3.

[0016] Step 8: After receiving the message, Device B decrypts the contents of the secure connection message. After successful decryption and verification of the consistency of the random number DEV, the encryption negotiation is completed. Both parties use the negotiated communication master key to encrypt the message.

[0017] Furthermore, the specific operation process for generating the public key P and private key K in step 1, and sending a request for authentication message to the group to which the device belongs to apply for authentication is as follows:

[0018] Step 1-1: Use the device's unique identifier (UUID) as the public and private keys for the SM2 elliptic curve public key cryptography algorithm;

[0019] Step 1-2: Generate a certificate CER = {P, UUID, TS, DUR} based on the device information; where P is the device public key, UUID is the unique device identifier, TS is the device issuance time, and DUR is the validity period.

[0020] Steps 1-3: The device sends a group authentication request message to its group. This message type is BACnet Confirmed Request. The service choice for the message is set to 38. This enumeration specifically indicates that this message is a ConfirmedSMDisCertificate-Request, which requests an encryption certificate. The specific structure is as follows:

[0021] ConfirmedSMDisCertificate-Request::=SEQUENCE{CER OCTET STRING};

[0022] Among them, the CER type is OCTET STRING, which is the certificate for the device.

[0023] Furthermore, after receiving the message, the devices in the group mentioned in step 2 generate and sign a certificate for the applicant, and return a certificate message. The specific operation process is as follows:

[0024] Step 2-1: After receiving the message, the devices in the group read the CER, use the SM3 hash algorithm to calculate the message digest of the certificate CER, and then encrypt the message digest with their own key. The encrypted content is the signature.

[0025] Step 2-2: Add the certificate and signature to the payload of the certificate message; this message type is BACnet Complex ACK; and set the message's Service Choice to 35. This enumeration specifically indicates that this message is a certificate message SMCertificate-ACK, the purpose of which is to request an encrypted certificate.

[0026]

[0027] Among them, CER is a byte string value, which is the received certificate; PCER is a byte string value, which is the device's public key; and SIG is a byte string value, which is the certificate's signature.

[0028] Furthermore, the specific steps for generating the new signature certificate in step 3 are as follows:

[0029] Step 3-1: The certificate content remains unchanged. Take at least 60% of the received signatures. If the total number is less than 4, take all; a maximum of 32 signatures can be taken. The distributed signature `DistributedSIG = SIG1||SIG2…SIGn`, where the signature SIGs are arranged in any order. Device A sends a connection request message to Device B with sequence number 0.

[0030] Furthermore, the specific operation process for device A to send a connection request message to device B in step 4 is as follows:

[0031] Step 4-1: Generate a random number RNUM with a length of 4 bytes. This number will be used as part of the communication master key.

[0032] Step 4-2: The device sends a distributed connection request message of type BACnet Confirmed Request; and sets the service choice of the message to 39. This enumeration specifically indicates that this message is a distributed connection request message SMSisConnect-Request, the purpose of which is to request a distributed encrypted connection. The specific structure is as follows:

[0033]

[0034] Among them, RNUM is of type Unsigned16 and is a random number; CER is a byte string value and is the device's certificate; DSIG is a byte string value and is the device's distributed certificate signature; SIGN is of type Unsigned16 and is the number of signatures used by the device in the distributed certificate signing; ENV is of type Unsigned16 and is an optional type used for later verification.

[0035] Step 4-3: This is an optional step. If you choose to implement it, you first need a random number DEV between 0 and 255, encrypt it with a public key to get a value, and then fill this value into the ENV field of the distributed connection request message.

[0036] Furthermore, the specific operation procedure for step 5 is as follows:

[0037] Step 5-1: Sign the other party's certificate information using your own saved public key;

[0038] Step 5-2: Verify whether the certificate has expired based on the issuance date (TS) and validity period (DUR);

[0039] Step 5-3: Compare the first 64 / SIGnum bytes of the signature with the first 64 / SIGnum bytes of the message digest in the certificate. If they match, the authentication is successful.

[0040] Step 5-4: If successful; first, a random number DEV between 0 and 255 is needed, which is then encrypted using the public key to obtain a value, and this value is filled into the ENV field of the distributed connection request message;

[0041] Step 5-5: If it fails, return a connection rejection message. This message type is BACnet Unconfirmed-Request-ACK. Set the service choice of the message to 40. This enumeration specifically indicates that this message is a RejectSMConnect-Request message, which aims to reject encrypted connections without any payload.

[0042] Steps 5-6: After receiving the connection refusal message, device A needs to repeat step 1, then repeat step 3, and select a certificate different from the one it has saved during the repetition. After completion, complete step 4 again.

[0043] Furthermore, the specific operational procedure for determining the security of connection messages in step 6 is as follows:

[0044] Step 6-1: Define a secure connection message SMSecurityConnect-ACK, which is of type BACnet Complex ACK; and set the service choice of the message to 37. This enumeration specifically indicates that this message is an SMSecurityConnect-ACK, and its purpose is to carry encrypted key information or encrypted information. The specific structure is as follows:

[0045]

[0046] The IsKey type is Boolean, used to indicate whether the message is a pre-master key or a regular encrypted message; the Content type is a byte string value. If IsKey is true, it is a pre-master key; otherwise, it is an encrypted byte string.

[0047] Advantages of this invention:

[0048] In this invention, the encryption algorithms used are the more secure SM2 elliptic curve public key cryptography algorithm [1], SM3 hash algorithm [2], and SM4 block cipher algorithm [3]. Since the algorithms are relatively novel and have not been cracked, they avoid the encryption security problems that other algorithms may bring. The authentication process adopts a decentralized distributed authentication process, which avoids the problems of data sharing difficulties, high trust costs, and easy node failures that occur in centralized authentication, making device authentication more private, secure, and convenient. The authentication process involves identity verification, key negotiation, etc. This dynamic authentication process improves message privacy and integrity, and is also easy to use compared to other methods. Attached Figure Description

[0049] Figure 1 This is a flowchart of the secure communication method based on distributed BACnet devices according to the present invention.

[0050] Figure 2 A flowchart for a BACnet device to request authentication from group devices. Detailed Implementation

[0051] The present invention will be further described below with reference to the accompanying drawings and embodiments. The described embodiments are only a part of all embodiments of the present invention. Other embodiments obtained by those skilled in the art based on these embodiments without inventive effort are all within the scope of protection of the present invention. The specific numbers, formulas, and parameter settings used in these embodiments are merely a set of preferred settings used in these embodiments, and should not be construed as limiting the scope of the present invention. Any modifications, improvements, and parameter settings made based on the concept of the present invention should all fall within the scope of protection of the present invention.

[0052] An example of a secure communication method for BACnet-based devices includes the following steps:

[0053] Step 1: Set up a system with 5 devices, namely A, B, C, D, and E; each device has computing power to perform encryption, decryption, and authentication processes, and the system time is set to September 30, 2022; first, the devices in the system begin initialization. Each device uses the SM2 elliptic curve public key cryptography algorithm to generate its own public key P and private key K, and sends a request for authentication message to the group to which the device belongs to apply for authentication.

[0054] Step 1-1: Generate public and private keys by using the device's unique identifier UUID as the password for the SM2 algorithm. The generated public key is 64 bytes long and the private key is 32 bytes long.

[0055] Taking device A as an example: its UUID is set to 1234, and the public key generated accordingly is (in hexadecimal form):

[0056] B29E1EA2B028E6BCE747665E68694EE564856601E206A8B90124BB8E9AF654C9BF3B0702BFCD27EF863BB882B9AD10235E5F72E81A1B08B4CE8B6118A9B5E7D0;

[0057] The private key is in hexadecimal format:

[0058] 9D73850B53DB4E06433BAEB843429A83034F285AB57085E3D3B6D75C99ABD807;

[0059] Step 1-2: Generate a certificate CER = {P, UUID, TS, DUR} according to your needs; where P is the device public key, UUID is the unique device identifier, TS is the device issuance time, and DUR is the validity period.

[0060] Steps 1-3: The device sends an authentication request message "Confirmed" to the group to which it belongs.

[0061] The SMDisCertificate-Request requires setting the message type in the BACnet protocol to BACnet Confirmed Request and the service choice to 38, as shown in the following structure:

[0062] Confirmed SMDisCertificate-Request::=SEQUENCE{CER OCTET STRING};

[0063] The specific content of the authentication request message from device A is as follows (in hexadecimal format).

[0064] B29E1EA2B028E6BCE747665E68694EE564856601E206A8B90124BB8E9AF654C9BF3B0702BFCD27EF 863BB882B9AD10235E5F72E81A1B08B4CE8B6118A9B5E7D0313233342C32303232303932332C316D;

[0065] The document provides the public key and UUID of device A, and states that it was issued on September 23, 2022, with a validity period of one month.

[0066] Step 2: After receiving the message, the devices in the group generate and sign a certificate for the applicant and return a certificate message.

[0067] Step 2-1: After receiving the message, the devices in the group read the CER, use the SM3 hash algorithm to calculate the message digest of the certificate CER, and then encrypt the message digest with their own key. The encrypted content is the signature.

[0068] Step 2-2: Add the certificate and signature to the payload of the certificate message SMCcertificate-ACK; the message type in the BACnet protocol needs to be set to BACnet Complex ACK; and the service choice of the message needs to be set to 35, with the following structure:

[0069]

[0070] The specific certificate message sent by device B to the device is as follows (in hexadecimal format):

[0071] B29E1EA2B028E6BCE747665E68694EE564856601E206A8B90124BB8E9AF654C9BF3B0702BFCD27E F863BB882B9AD10235E5F72E81A1B08B4CE8B6118A9B5E7D0313233342C32303232303932332C31 6D8D3E794170A94459205325A9B5410CB4525BE51AF9644A6CAF6480C9FDC57B4 7975F071D2943DB15A4A965B98C625873611293FEB1310DC0D2472C2301CB69B2.

[0072] Step 3: The requesting party saves the public key and generates a new signing certificate based on the received certificate message;

[0073] Step 3-1: Keep the certificate content unchanged. Take at least 60% of the received signatures. If the total number is less than 4, take all of them. Take a maximum of 32 signatures. In practice, considering the balance between performance and security, choose 8-16 signatures if possible. Distributed signature: DistributedSIG = SIG1||SIG2…SIGn, where SIG can be arranged in any order.

[0074] The signatures of the four devices for device A are as follows (in hexadecimal form):

[0075] 975F071D2943DB15A4A965B98C625873611293FEB1310DC0D2472C2301CB69B2

[0076] B2395D22073CDCE904F2E3A5E8934B9A942B906F64DD978AF044033107D714D0

[0077] 4E8B2BFED3998C70D097514E6FAC670CC67F425198B48AE6AE08F3334C47E9D8

[0078] D92A73320B2C27B95FFCDDA0B5C39CDB3D3C479DA92E24418729BEFF9C884608

[0079] The generated distributed signature DistributedSIG = SIG1||SIG2…SIG4 is as follows (in hexadecimal form):

[0080] 975F071D2943DB15B2395D22073CDCE94E8B2BFED3998C70D92A73320B2C27B9.

[0081] Step 4: Device A sends a connection request message to Device B with a sequence number of 0;

[0082] Step 4-1: Generate a random number RANa with a length of 4 bytes. This number will be used as part of the communication master key. The random number generated here is 99ABD807.

[0083] Step 4-2: The device sends a distributed connection request message, SMSIConnect-Request, to the Certificate Authority (CA) server. The message type in the BACnet protocol needs to be set to BACnet Confirmed Request, and the service choice for the message needs to be set to 39, as shown in the following structure:

[0084]

[0085] The specific distributed connection request message sent by device B to device B is as follows (in hexadecimal format).

[0086] 99ABD807B29E1EA2B028E6BCE747665E68694EE564856601E206A8B90124BB8E9AF654C9BF3B0702BFCD27EF863BB882B9AD1 0235E5F72E81A1B08B4CE8B6118A9B5E7D0975F071D2943DB15B2395D22073CDCE94E8B2BFED3998C70D92A73320B2C27B904;

[0087] The random number, the certificate of device A, and the distributed signature stored by device A, where the number of signatures is 4;

[0088] Step 4-3: This is an optional step. If you choose to implement it, you first need a random number DEV between 0 and 255, encrypt it with a public key to get a value, and then fill this value into the ENV field of the distributed connection request message.

[0089] Step 5: After receiving the request, Device B verifies the signature SIGa and saves the random number RANa. After confirming the security of A, it generates a random number DEV, encrypts DEV using the public key in Device A's certificate CERa using the SM2 elliptic curve public key cryptography algorithm to obtain an encrypted value, and returns a connection request message with the encrypted value and a sequence number Invoke ID of 1. If it fails, it returns a connection rejection message, and Device A needs to apply for a certificate again and initiate a connection request.

[0090] Step 5-1: Sign the other party's certificate information using the public key stored in device B;

[0091] Step 5-2: The system time is September 30, 2022, while the issuance time is September 23, 2022, with a validity period of 1 month. This indicates that the verification certificate has not expired.

[0092] Step 5-3: Here, device B has already signed device A and stored it in device A's distributed signature; therefore, compare the first 16 bytes of the signature with the first 16 bytes of the second signature in the certificate, which means the authentication is successful.

[0093] Step 5-4: If successful; generate a random number RANb = 11AC8017, which will be used as part of the communication master key. Here, the generated random number is 99ABD807; then generate a random number DEV between 0 and 255, here 46, and encrypt it using the public key to obtain the following value:

[0094] C3A3DD00395C15B5454154AD1BB357E399ADE612287B4DE4395BD2492266DD4BCF0BF951956D3212252A52FCE121E78A9 1DB489514ADDF48F8B841DB711C18EFAC0F4C61713DAF186D115E68D066303D20F17AF3B88EAB858094613FE3A2FB1E0F;

[0095] And fill this value into the ENV field of the distributed connection request message;

[0096] Step 5-5: If it fails, return a RejectSMConnect-Request message. You need to set the message type in the BACnet protocol to Unconfirmed Request-ACK and set the service choice of the message to 40, without any payload.

[0097] Steps 5-6: After receiving the connection refusal message, device A needs to repeat step 1, then repeat step 3, and select a certificate different from the one it has saved during the repetition. After completion, complete step 4 again.

[0098] Step 6: After receiving the connection request message, Device A verifies the security of Device B using the same method, saves the random number RANb, and decrypts the encrypted value ENV using its own private key to obtain the random number DEV. Device A uses the public key in the certificate CERb to encrypt the randomly generated pre-master key PMK=1234567812345678 using the SM2 elliptic curve public key cryptography algorithm, sends a secure connection message to Device B, and sets the scheduling number (InvokeID) to DEV=46 and the sequence number to 2.

[0099] Step 6-1: Send the secure connection message SMSecurityConnect-ACK. This requires setting the message type in the BACnet protocol to BACnet Complex ACK and the service choice to 37, as shown below:

[0100]

[0101] The secure connection message sent by device A to device A is as follows (in hexadecimal format):

[0102] 01CD723DA990E813D9F4FF62D47E8B31A9CFEFF1EC1F02DD4835628F81FE1D27BC03D739871CCF8B12B5074F7730762C6E58C7273 291AB0C024BBD23AC806A469B09B1347B89FAB0BE5AEED8B9C19016215DAAEE2527C51A497039C02F0F94E6D668F6BE1B8016CB7C.

[0103] Step 7: Device B uses its private key to decrypt and obtain the 8-byte pre-master key PMK. It compares the random number DEV in the InvokeID with the previously set random number. At this point, both devices have obtained the negotiated communication master key MK = RANa||RANb||PMK = 99ABD80711AC80171234567812345678. To verify the feasibility of communication, Device B uses the communication key to encrypt a secure connection message with an encryption option IsKey set to "No" and the content is "Use the communication master key to encrypt the random number DEV = 46 using the SM4 block cipher algorithm." The sequence number is 3.

[0104] Step 8: After receiving the message, Device B decrypts the contents of the secure connection message. After successful decryption and verification of the consistency of the random number DEV, the encryption negotiation is completed. Both parties use the negotiated communication master key to encrypt the message.

[0105] The table below shows the communication time test results under different communication methods. The "normal method" refers to communication without any operation, while the "encryption-only method" refers to communication using the fixed SM4 block cipher algorithm.

[0106]

[0107]

[0108] As shown in the table, the communication time of this invention is longer than that of the conventional method. This is because it uses an encryption algorithm. During each communication, this invention involves a key negotiation process, which provides higher communication security compared to communication using a fixed SM4 block cipher algorithm. Furthermore, after the negotiation is completed, the communication time is the same as that of the encryption-only method. In summary, this invention achieves secure communication for BACnet devices while maintaining high communication efficiency.

[0109] References

[0110] [1] GM / T 0003.1-2012.SM2 Elliptic Curve Public Key Cryptography Algorithm [S]. Beijing: State Cryptography Administration, 2012.

[0111] [2] GM / T 0004-2012. SM3 cryptographic hash algorithm [S]. Beijing: State Cryptography Administration, 2012.

[0112] [3]GM / T 0002-2012.SM4 block cipher algorithm [S]. Beijing: State Cryptography Administration, 2012.

Claims

1. A secure communication method based on a distributed BACnet device, characterized in that, The authentication process involves sending a certificate request message to the group; devices within the group generate and sign a certificate for the applicant and return a certificate message to complete the authentication; when communication is needed, device A sends a connection request message to device B; device B will perform security authentication upon receiving the request, and if the authentication fails, device B will return a connection rejection message, which device A will then re-authenticate within the group. If the authentication is successful, Device B sends a connection request message with verification information; Device A receives and verifies the security of Device B, then uses Device B's public key to encrypt a randomly generated pre-master key using the SM2 elliptic curve public key cryptography algorithm, and sends it to Device B; Device A uses the negotiated communication master key to encrypt a secure connection message and sends it to Device B. Device B completes the encryption negotiation by decrypting and verifying the schedule number; the specific steps are as follows: Step 1: System initialization. Devices connected to the system use the SM2 elliptic curve public key cryptography algorithm to generate their own public key P and private key K, and send a request for authentication message to the group to which the devices belong to apply for authentication. Step 2: After receiving the message, the devices in the group generate and sign a certificate for the applicant and return a certificate message. Step 3: The requesting party saves the public key and generates a new signing certificate based on the received certificate message; Step 4: Device A sends a connection request message to Device B with a sequence number of 0; Step 5: After receiving the request, device B verifies the signature SIGa and saves the random number RANa. After confirming the security of A, it generates a random number DEV, encrypts DEV using the public key in device A's certificate CERa using the SM2 elliptic curve public key cryptography algorithm to obtain an encrypted value, and returns a connection request message with the encrypted value and a sequence number of 1. If it fails, it returns a connection rejection message, and device A needs to apply for a certificate again and initiate a connection request. Step 6: After receiving the connection request message, Device A verifies the security of Device B using the same method, saves the random number RANb, and decrypts the encrypted value ENV using its own private key to obtain the random number DEV. If secure, Device A uses the public key in the certificate CERb to encrypt the randomly generated pre-master key PMK using the SM2 elliptic curve public key cryptography algorithm, sends a secure connection message to Device B, and sets the schedule number to DEV and the sequence number to 2. Step 7: Device B uses its private key to decrypt the 8-byte pre-master key PMK and compares the random number DEV in the scheduling number with the previously set random number to ensure the security of this negotiation. At this point, both devices have obtained the negotiated communication master key MK=RANa||RANb||PMK. To verify the feasibility of communication, Device B uses the communication key to encrypt an encryption option IsKey (not specified), which contains a secure connection message that uses the communication master key to encrypt the random number DEV using the SM4 block cipher algorithm, with a sequence number of 3. Step 8: After receiving the message, Device B decrypts the contents of the secure connection message. After successful decryption and verification of the consistency of the random number DEV, the encryption negotiation is completed. Both parties use the negotiated communication master key to encrypt the message.

2. The secure communication method based on a distributed BACnet device according to claim 1, characterized in that, The steps described in step 1, which involve generating a public key P and a private key K and sending a request for authentication to the group containing the devices, are as follows: Step 1-1: Use the device's unique identifier (UUID) as the public and private keys for the SM2 elliptic curve public key cryptography algorithm; Step 1-2: Generate a certificate CER={P,UUID,TS,DUR} based on the device information; where P is the device public key, UUID is the unique device identifier, TS is the device issuance time, and DUR is the validity period. Steps 1-3: The device sends a group authentication request message to its group. This message type is BACnet Confirmation Request. The service option of the message is set to 38. This enumeration specifically indicates that this message is a ConfirmedSMDisCertificate-Request authentication message, the purpose of which is to request an encryption certificate. The specific structure is as follows: ConfirmedSMDisCertificate-Request :: = SEQUENCE {CEROCTET STRING}; Among them, the CER type is OCTET STRING, which is the certificate for the device.

3. The secure communication method based on a distributed BACnet device according to claim 2, characterized in that, After receiving the message, the devices in the group mentioned in step 2 generate and sign a certificate for the applicant and return a certificate message. The specific operation process is as follows: Step 2-1: After receiving the message, the devices in the group read the CER, use the SM3 hash algorithm to calculate the message digest of the certificate CER, and then encrypt the message digest with their own key. The encrypted content is the signature. Step 2-2: Add the certificate and signature to the payload of the certificate message; this message type is BACnet Complex Response; and set the message service option to 35, which specifically indicates that this message is a certificate message SMCertificate-ACK, the purpose of which is to request an encrypted certificate. SMCertificate-ACK :: = SEQUENCE { CER OCTET STRING, PCER OCTET STRING, SIG OCTET STRING Among them, CER is a byte string value, which is the received certificate; PCER is a byte string value, which is the device's public key; and SIG is a byte string value, which is the certificate's signature.

4. The secure communication method based on a distributed BACnet device according to claim 3, characterized in that, The specific steps for generating a new signature certificate in step 3 are as follows: Step 3-1: The certificate content remains unchanged. Take at least 60% of the received signatures. If the total number is less than 4, take all of them. Take a maximum of 32 signatures. Distributed signature DistributedSIG=SIG1||SIG2…SIGn, where the signature SIGs are arranged in any order. Device A sends a connection request message to Device B with sequence number 0.

5. The secure communication method based on a distributed BACnet device according to claim 4, characterized in that, In step 4, device A sends a connection request message to device B. The specific operation process is as follows: Step 4-1: Generate a random number RNUM with a length of 4 bytes. This number will be used as part of the communication master key. Step 4-2: The device sends a distributed connection request message of type BACnet acknowledgment request; and sets the service option of the message to 39. This enumeration specifically indicates that this message is a distributed connection request message SMSisConnect-Request, the purpose of which is to request a distributed encrypted connection. The specific structure is as follows: SMDisConnect-Request :: = SEQUENCE { RNUM Unsigned16, CER OCTET STRING, DSIG OCTET STRING, SIGN Unsigned16, ENV Unsigned16 (Optional) Among them, RNUM is of type Unsigned16 and is a random number; CER is a byte string value and is the device's certificate; DSIG is a byte string value and is the device's distributed certificate signature; SIGN is of type Unsigned16 and is the number of signatures used in the distributed certificate signing process; ENV is of type Unsigned16 and is used for later verification. Step 4-3: A random number DEV between 0 and 255 is needed. Encrypt the DEV using the public key to obtain a value and fill this value into the ENV field of the distributed connection request message.

6. The secure communication method based on a distributed BACnet device according to claim 5, characterized in that, The specific operation process for step 5 is as follows: Step 5-1: Sign the other party's certificate information using your own saved public key; Step 5-2: Verify whether the certificate has expired based on the issuance date (TS) and validity period (DUR); Step 5-3: Compare the first 64 / SIGnum bytes of the signature with the first 64 / SIGnum bytes of the message digest in the certificate. If they match, the authentication is successful. Step 5-4: If successful; first, a random number DEV between 0 and 255 is needed, which is then encrypted using the public key to obtain a value, and this value is filled into the ENV field of the distributed connection request message; Step 5-5: If it fails, return a connection rejection message. This message type is a BACnet non-acknowledgment response request message; and set the service option of the message to 40. This enumeration specifically indicates that this message is a RejectSMConnect-Request message, the purpose of which is to reject encrypted connections without any payload. Steps 5-6: After receiving the connection refusal message, device A needs to repeat step 5-1, then repeat step 5-3, and select a certificate different from the one it has saved during the repetition. After completion, complete step 5-4 again.

7. The secure communication method based on a distributed BACnet device according to claim 6, characterized in that, The specific steps for ensuring connection message security in step 6 are as follows: Step 6-1: Define a secure connection message SMSecurityConnect-ACK, which is of type BACnet Complex Response; and set the message's service option to 37. This enumeration specifically indicates that this message is an SMSecurityConnect-ACK, and its purpose is to carry encrypted key information or encrypted information. The specific structure is as follows: SMSecurityConnect-ACK :: = SEQUENCE { IsKey Boolean Content OCTET STRING } The IsKey type is Boolean, used to indicate whether the message is a pre-master key or a regular encrypted message; the Content type is a byte string value. If IsKey is true, it is a pre-master key; otherwise, it is an encrypted byte string.

Images