A lightweight secure communication method, electronic device and storage medium

Abstract

The application provides a lightweight secure communication method, an electronic device and a storage medium. The method is applied to a first device and includes a key negotiation process. The key negotiation process includes the following steps: sending a negotiation request to a second device that has been authenticated by security, the negotiation request carrying a first identifier of the first device and a first encryption parameter generated by the first device according to a first random number and a pre-shared key; receiving a negotiation response returned by the second device, the negotiation response carrying a second identifier of the second device and a second encryption parameter generated by the second device; sending a negotiation verification request to the second device, the negotiation verification request carrying a first ciphertext and a first message authentication code, so that the second device generates a negotiation verification response; and receiving the negotiation verification response returned by the second device. The application reduces complex calculation operations through an efficient key negotiation process, thereby reducing the calculation burden of the device, achieving lightweight secure communication, and ensuring the confidentiality and security of communication between the two parties.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a lightweight secure communication method, electronic device and storage medium. Background Technology

[0002] During network communication, a series of technologies and mechanisms are employed to verify the identities of both communicating parties, ensuring the confidentiality, integrity, and non-repudiation of information, thereby protecting network communication from security threats such as unauthorized access, tampering, forgery, and eavesdropping. Ensuring network communication security is crucial for protecting user privacy, maintaining data integrity, and ensuring business continuity.

[0003] Current network security communication methods that provide security for network communication systems place a heavy computational burden on devices and have high resource requirements, making them unsuitable for porting to devices with limited computing power and content capacity.

[0004] Therefore, lightweight secure communication methods have become an inevitable choice to adapt to the resource constraints of these devices. Summary of the Invention

[0005] In view of the above problems, embodiments of this application are proposed to disclose a lightweight secure communication method, electronic device and storage medium that overcomes or at least partially solves the above problems.

[0006] In a first aspect, embodiments of this application disclose a lightweight secure communication method applied to a first authentication device, the lightweight secure communication method comprising: A negotiation request is sent to a second device that has already passed mutual security authentication. The negotiation request carries the first identifier of the first device and the first encryption parameters generated by the first device based on a first random number and a pre-shared key. The second device receives a negotiation response, which carries a second identifier of the second device and a second encryption parameter generated by the second device. The second encryption parameter is generated by the second device through encryption based on a first random number and a second random number obtained by decrypting the first encryption parameter using the pre-shared key and the shared key. Decrypt the second encryption parameter to obtain the first random number and verify its correctness. If the verification is correct, obtain the master key and verification key based on the first random number and the second random number using key derivation. Encrypt the first plaintext according to the master key to generate the first ciphertext. Obtain the first message authentication code of the first plaintext based on the hash function and the verification key. A negotiation verification request is sent to the second device. The negotiation verification request carries the first ciphertext and the first message authentication code, so that the second device can obtain a master key and a verification key based on the first random number and the second random number using key derivation, and decrypt the first ciphertext according to the master key to generate a second plaintext; obtain a second message authentication code of the second plaintext based on a hash function and the verification key; compare the first message authentication code and the second message authentication code, and if they match, generate a negotiation verification response; Receive the negotiation verification response returned by the second device.

[0007] Secondly, embodiments of this application disclose a lightweight secure communication method applied to a second device. The lightweight secure communication method includes a key negotiation process, which includes: The system receives a negotiation request sent by a first device that has already mutually authenticated with the first device. The negotiation request carries a first identifier and a first encryption parameter of the first device. The first encryption parameter is generated by the first device through encryption based on a first random number and a pre-shared key. Decrypt the first encryption parameter to obtain a first random number, and encrypt the second encryption parameter based on the first random number, the second random number, and the pre-shared key; The negotiation response is sent to the first device, and the negotiation response carries the second identifier of the second device and the second encryption parameter, so that the first device can decrypt the first random number according to the second encryption parameter and verify whether it is correct. If the verification is correct, the first device uses the first random number and the second random number to derive the master key and the verification key; encrypts the first plaintext according to the master key to generate the first ciphertext, and obtains the first message authentication code of the plaintext based on the hash function and the verification key. Receive a negotiation verification request sent by the first device, wherein the negotiation verification request carries the first ciphertext and the first message authentication code; Based on the first random number and the second random number, a master key and a verification key are obtained using key derivation. The first ciphertext is decrypted using the master key to generate the second plaintext. A second message authentication code for the second plaintext is obtained based on a hash function and the verification key. The first message authentication code and the second message authentication code are compared. If they match, a negotiation verification response is generated. The negotiation verification response is sent to the first device.

[0008] Thirdly, embodiments of this application disclose an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, when the processor executes the computer program, it implements a lightweight secure communication method as disclosed in any possible embodiment of the first aspect or a lightweight secure communication method as disclosed in any possible embodiment of the second aspect.

[0009] Fourthly, embodiments of this application disclose a computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program that executes the lightweight secure communication method disclosed in any possible embodiment of the first aspect or the lightweight secure communication method disclosed in any possible embodiment of the second aspect.

[0010] Compared with existing technologies, the beneficial technical effects of the embodiments of this application are as follows: The lightweight secure communication method provided by the embodiments of this application reduces complex computational operations through an efficient key negotiation process, thereby reducing the computational burden on the device and realizing lightweight secure communication, which is particularly important for resource-constrained devices. The key negotiation process is implemented by sending and receiving negotiation requests, negotiation responses, and negotiation verification requests and responses, ensuring the confidentiality and security of communication between the two parties. Attached Figure Description

[0011] The accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this application in any way. Furthermore, the shapes and scales of the components in the drawings are merely illustrative to aid in understanding this application and do not specifically limit the shapes and scales of the components. Those skilled in the art, guided by the teachings of this application, can select various possible shapes and scales to implement this application according to specific circumstances. In the drawings: Figure 1 This is a schematic diagram of the steps of the lightweight secure communication method applied to a first device provided in an embodiment of this application; Figure 2 This is a schematic diagram of the steps of the lightweight secure communication method applied to a second device provided in an embodiment of this application; Figure 3 This is an application architecture diagram of the lightweight secure communication method provided in the embodiments of this application. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0013] In the description of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more features.

[0014] Figure 1 This application illustrates a lightweight secure communication method applied to a first device. The lightweight secure communication method includes a key negotiation process, through which the first device and the second device implement a shared master key MSK and verification key PSK.

[0015] The key negotiation process includes the following steps: Step S101: Send a negotiation request to the second device that has already passed security authentication with the first device. The negotiation request carries the first identifier of the first device and the first encryption parameter generated by the first device based on the first random number and the pre-shared key.

[0016] In this embodiment, both the first device and the second device have a pre-shared key (PSK). The first device can select a first random number R. A (Secure random number), based on the first random number R A Encryption is performed using the pre-shared key PSK, as shown in the following expression: (TSK A T1)=ENC PSK (R A UID A ); Among them, TSK A T1 is the first encryption parameter; T1 is the authentication code, which is used to verify integrity; the first identifier is the UID. A For AAD data (optional), only verify integrity, do not encrypt.

[0017] As an example, in the embodiments of this application, the encryption process uses a form such as ENC. K The formula (P, A) indicates that the encryption method used is a symmetric encryption algorithm in the form of AEAD, such as AES-GCM or ChaCha20-Poly1305.

[0018] As an example, ENC K In (P, A), K is the encryption key, P is the data to be encrypted (i.e., plaintext), and A is AAD data (optional). A only verifies integrity and does not perform encryption. DEC K (C,A,T) represents the corresponding decryption algorithm, K is the decryption key, C is the ciphertext, A is the AAD data (optional), and T is the authentication code.

[0019] Step S102: Receive the negotiation response returned by the second device, the negotiation response carrying the second identifier UID of the second device. B The second encryption parameter TSK generated by the second device B .

[0020] The second device decrypts the first encryption parameter TSK using the pre-shared key PSK. A Obtain the first random number R A T1 is the first authentication code, used to verify integrity, and its expression is as follows: (R) A T1) = DEC PSK (TSK) A UID A (T1) Second encryption parameter TSK B For the second device, based on the first encryption parameter TSK A The first random number R obtained through decryption A The second random number R selected by the second device B And the pre-shared key PSK is used for encryption generation, as shown in the following expression: (TSK B T2)=ENC PSK (R A ||R B UID B ); Where "||" represents the concatenation operation, and the second identifier is the UID. B For AAD data (optional), only verify integrity, do not encrypt.

[0021] The first device uses the second encryption parameter TSK B Decrypt to obtain R A ||R B And verify the first random number R A Is it correct? T2 is the second authentication code, used to verify integrity. Its expression is as follows: (R) A ||R B T2) = DEC PSK (TSK) B UID B (, T2) If the verification is successful, then based on the first random number R A Second random number R B The master key MSK and the verification key HSK are obtained using the key derivation algorithm KMAC.

[0022] KMAC stands for Key-based Message Authentication Code, which is a message authentication code algorithm based on the Keccak hash function.

[0023] The master key MSK and verification key HSK are obtained using the key derivation algorithm KMAC as follows: MSK||HSK=KMAC(R A ||R B (X, L, "KDF"); Here, MSK||HSK represents the concatenation of the master key MSK and the verification key PSK. In the example, X is a customized string, which can be empty; L is the output key length. For example, if MSK and HSK are both 256 bits, then L is 512. In a specific embodiment, KMAC can calculate and output a longer key (length less than 2) in one step. 2040 (This can be flexibly configured for use, as long as both parties keep it consistent); "KDF" indicates that this calculation is used for key derivation.

[0024] Based on the master key MSK, the first plaintext Data A Encryption is performed to generate the first ciphertext EData A The expression is as follows: (EData A T3)=ENC MSK (Data A ); T3 is the third authentication code, used to verify integrity.

[0025] The first plaintext Data is obtained based on the hash function and the verification key PSK. A First Message Authentication Code (HMAC) A The expression is as follows: HMAC A =HMAC HSK (Data A ).

[0026] Step S103: Send a negotiation verification request to the second device. The negotiation verification request carries the first encrypted text EData. A And the first message authentication code HMAC A So that the second device is based on the first random number R ASecond random number R B The master key MSK and verification key HSK are obtained using key derivation, in the same way as the first device; the first ciphertext EData is processed based on the master key MSK. A Decryption to generate second plaintext Data B The expression is as follows: (Data B T3)=DEC MSK (EData A T3); The second device obtains the second plaintext Data based on the hash function and the verification key HSK. B Second Message Authentication Code (HMAC) B The expression is as follows: HMAC B =HMAC HSK (Data B ); The second device is based on the first message authentication code HMAC. A Second Message Authentication Code (HMAC) B A comparison is performed, and if they match, a negotiation verification response is generated.

[0027] Step S104: Receive the negotiation verification response returned by the second device.

[0028] If any sub-process of the above negotiation request or negotiation verification request fails verification, a negotiation verification failure response will be returned, ending the key negotiation process; if the first message authentication code HMAC... A Second Message Authentication Code (HMAC) B If they are the same, then the master key MSK and the verification key HSK have been successfully negotiated and verified, and a successful negotiation and verification response is returned.

[0029] In some embodiments, in addition to both having a pre-shared key (PSK) built-in, the trusted first and second devices also have their own pre-built certificates and a whitelist of certificate fingerprints for the trusted intervening parties. The embodiments can leverage the security of the PSK and the trust in the trusted devices to tailor the certificate authentication process, achieving lightweight security authentication.

[0030] Optionally, the first and second devices can be microcontroller units (MCUs), also known as single-chip microcomputers, which are integrated circuit chips that integrate a processor core, memory, input / output interfaces, and other peripherals. Designed specifically for embedded systems, they are characterized by small size, low power consumption, and powerful functionality, and are widely used in various lightweight devices.

[0031] As an example, the provided lightweight secure communication method includes a security authentication process before the key negotiation process, which includes: The first pre-set certificate CER of the first device A Send to the second device so that the second device can verify the first pre-installed certificate CER. A If the certificate fingerprint is in the whitelist, the security authentication of the first device is successful and a successful authentication response is returned; otherwise, the second device refuses to connect. Receive the second pre-set certificate CER sent by the second device. B Verify the second pre-built certificate CER B If the certificate fingerprint is in the whitelist, the security authentication of the second device is successful, and a successful authentication response is returned; otherwise, the connection is rejected.

[0032] Furthermore, if access control is required, it can be further refined in the whitelist, and adaptation can be performed during verification.

[0033] Furthermore, if permissions need to be adjusted (added, deleted, or modified), the whitelist can be updated via UDS / OTA; if a certificate needs to be replaced due to revocation, security vulnerabilities, changes in encryption technology, or expiration (or impending expiration), the certificate can be updated via UDS / OTA. If a pre-configured key is leaked, the pre-configured key can be updated via UDS / OTA, and key negotiation can be renegotiated. UDS / OTA ensures the secure transmission of sensitive data throughout all of the above processes.

[0034] This application embodiment achieves two-way identity security authentication between the first and second devices through a security authentication process, ensuring the trustworthiness of both communicating parties. By checking whether a pre-set certificate is in the whitelist, the legitimacy of the device can be quickly and effectively verified, preventing unauthorized devices from accessing the communication network. Maintaining the whitelist is relatively simple; administrators can easily add or remove trusted devices or certificates.

[0035] In some embodiments, to prevent replay attacks, both communicating parties may maintain a local counter. As an example, the key negotiation process further includes: the first device setting a first counter SQ for the second device. B Set the first counter SQ B The result is sent to the second device so that the second device can set the first counter SQ. B The result is compared with the second counter SQ stored locally. A The results are compared; if they match, a successful verification response is returned, and the second counter SQ is incremented. A The result is incremented by one, where the second counter is the counter set by the second device for the first device; if they are inconsistent, a verification error response is returned, and the second counter SQ is incremented.A The result is reset to zero, and the connection is rejected; If the first device receives a successful verification response, the first counter SQ B Add one to the result; If the first device receives a verification error response, it will reset the result of the first counter SQB to zero and restart the key negotiation process.

[0036] This application embodiment introduces a first timer and a second timer, and exchanges the values ​​of these counters in the negotiation probe request and the negotiation verification response. This ensures that the key negotiation process will not be repeatedly started due to repeated requests, which helps to reduce unnecessary computation and network overhead.

[0037] In some embodiments, the lightweight secure communication method further includes a key negotiation probing process before the key negotiation process; the key negotiation probing process includes: A negotiation attempt request is sent to a second device that has already passed mutual security authentication, so that the second device generates and returns a test error signal or a test success signal based on the negotiation attempt request. The negotiation attempt request carries the first device's first identifier and encrypted first test request data. The encrypted first test request data is generated by the first device using its own first identifier and the result of its first counter, encrypted with a master key. A test error response is generated when the second device searches for the corresponding master key shared with it based on the first identifier; if no corresponding master key is found, the first device generates and returns the data. Alternatively, if the second device finds the corresponding master key, it decrypts the encrypted first test request data using the master key, obtains the result of the first counter, compares the result of the first counter with the result of a second counter stored locally, and generates and returns the data if they do not match. When a test error signal is generated, the second device resets the result of the second counter to zero. A test success response is generated and returned when the result of the first counter matches the result of the second counter stored locally. If the first device receives a test error response, it resets the result of the first counter to zero and starts the key negotiation process; if the first device receives a test success response, it increments the result of the first counter by one and does not start the key negotiation process.

[0038] The second device can locally store an association table of the first device's first identifier and corresponding master key (MSK). It can look up the master key shared with the second device by using the first device's first identifier. Each first device and the second device have their own unique shared master key (MSK). This means that if a key is leaked or compromised, the impact is limited to the device associated with that key, thereby reducing the overall system security risk.

[0039] The negotiation probe request carries the first identifier (UID) of the first device.A And the first probing request for encrypted data EData C The first probe request encrypted data EData C The first device is based on its first identifier UID. A With the first counter SQ B The result is generated using the master key MSK, with the following expression: (EData) C T5)=ENC MSK (UID) A ⊕SQ B UID A ); Here, "⊕" represents the XOR operation, and T5 is the fifth authentication code used to verify integrity.

[0040] The test error response is that the second device responds according to the first identifier UID. A The system searches for the master key (MSK) shared with the second device. If no corresponding master key (MSK) is found, it generates and returns the corresponding master key (MSK). Alternatively, if the second device finds the corresponding master key (MSK), it uses the master key (MSK) to decrypt the encrypted data EData of the first probe request. C Obtain the first counter SQ B The result is expressed as follows: (Data) c T5)=DEC MSK (EData) C UID A (T5) Data c =UID A ⊕SQ B ; Set the first counter SQ B The result is compared with the second counter SQ stored locally. A The results are compared, and if they are inconsistent, a trial error response is generated and returned.

[0041] The successful response to the trial is if the first counter SQ B The result is compared with the second counter SQ stored locally. A If the results are consistent, the second device generates and returns.

[0042] This application embodiment incorporates a key negotiation probing process. If the first device wants to communicate with the second device, it first checks whether a shared master key (MSK) exists locally. If it does, a key negotiation probing process is initiated. If the probing is successful, the existing shared master key (MSK) can be used directly. The key negotiation process is only initiated if the key negotiation probing process fails (e.g., due to counter inconsistency, failure to find the master key), thus avoiding repeated negotiation caused by network latency, duplicate requests, or other reasons, thereby saving computing and network resources.

[0043] In some embodiments, to improve the security and efficiency of protocol interaction, the authentication process and the key negotiation process can be integrated and optimized. That is, the first plaintext in step S103 is generated based on the freshness value and the first pre-set certificate of the first device, and the expression is: Data A =FV||CER A ; Among them, Data A First plaintext, FV is freshness value, CER A This is the first pre-installed certificate for the first device.

[0044] Freshness Value (FV) is an identifier that represents changes over time or continuous updates of data; it can be a timestamp or a sequence number.

[0045] A timestamp records the exact time when data or information was generated or updated.

[0046] Whenever data or information is updated, the serial number increases, recording the number of times the data has been updated.

[0047] The first device sends a negotiation verification request to the second device, which also enables the second device to decrypt and obtain the second plaintext, and then verify the fresh value. If the fresh value is valid, the second device calculates the certificate fingerprint of the first pre-set certificate and verifies whether the certificate fingerprint is in the whitelist. Otherwise, the second device refuses to connect.

[0048] As an example, by comparing the time difference between the timestamp and the current time, the freshness of the data or information, i.e. its validity, can be determined. If the time difference exceeds 30 seconds (which can be set according to the actual situation), it is considered a replay of the message, and the second device refuses to connect.

[0049] This application's embodiments prevent replay attacks by incorporating timestamps. During communication, if an attacker intercepts a previous message and attempts to resend it, the receiver can check the timestamp's freshness due to the real-time nature of the timestamp, thus refusing to receive outdated messages and enhancing communication security. Certificates, as identifiers of device identity, ensure the authenticity of both communicating parties through verification.

[0050] The second device decrypted the second plaintext data. B Next, it is necessary to verify whether the timestamp is valid. If it is valid, then the first pre-built certificate CER is calculated. A Certificate fingerprint FP A It then verifies whether the certificate is in the built-in certificate whitelist. Similarly, a two-way authentication process can be added, as described above. After a successful handshake, both parties' counters SQ are set to 1. Other processes remain unchanged.

[0051] Optional, the length of the secure random number can be selected according to actual needs, but 128 bits or more is recommended to improve security.

[0052] Based on the same technical concept as the above embodiments, this application also provides a lightweight secure communication method applied to a second device, such as... Figure 2 As shown, the lightweight secure communication method includes a key negotiation process, which includes: Step S201: Receive a negotiation request sent by a first device that has already passed security authentication with the first device. The negotiation request carries the first identifier of the first device and the first encryption parameter generated by the first device based on the first random number and the pre-shared key.

[0053] Step S202: Decrypt the first encryption parameter to obtain the first random number, and encrypt the second encryption parameter based on the first random number, the second random number, and the pre-shared key; The negotiation response is sent to the first device, which carries the second identifier and the second encryption parameter of the second device. The first device decrypts the data according to the second encryption parameter to obtain the first random number and verifies its correctness. If the verification is correct, the first device uses the first random number and the second random number to derive the master key and the verification key. The first plaintext is encrypted according to the master key to generate the first ciphertext. The first message authentication code of the plaintext is obtained based on the hash function and the verification key. Step S203: Receive a negotiation verification request sent by the first device. The negotiation verification request carries the first ciphertext and the first message authentication code. Step S204: Based on the first random number and the second random number, obtain the master key and the verification key by key derivation; decrypt the first ciphertext according to the master key to generate the second plaintext; obtain the second message authentication code of the second plaintext based on the hash function and the verification key; compare the first message authentication code and the second message authentication code, and if they match, generate a negotiation verification response; send the negotiation verification response to the first device.

[0054] In some embodiments, the lightweight secure communication method further includes a security authentication process before the key negotiation process; the security authentication process includes: sending a second pre-configured certificate of the second device to the first device, so that the first device verifies whether the second pre-configured certificate is in the whitelist; if it is in the whitelist, the security authentication of the second device is successful and an authentication success response is returned; otherwise, the first device refuses to connect. Receive the first pre-configured certificate sent by the first device, verify whether the first pre-configured certificate is in the whitelist. If it is in the whitelist, the security authentication of the first device is successful and a successful authentication response is returned; otherwise, the connection is rejected.

[0055] Furthermore, the key negotiation process also includes: setting a second counter for the first device, sending the result of the second counter to the first device, so that the second device compares the result of the second counter with the result of the first counter stored locally. If they match, a verification success response is returned, and the result of the second counter is incremented by one, where the first counter is the counter set by the first device for the second device; if they do not match, a verification error response is returned, the result of the second counter is reset to zero, and the connection is rejected. If the second device receives a successful verification response, the result of the first counter is incremented by one; if the second device receives an incorrect verification response, the result of the first counter is reset to zero, and the key negotiation process is restarted.

[0056] Furthermore, the lightweight secure communication method includes a key negotiation probe process before the key negotiation process; the key negotiation probe process includes: receiving a negotiation probe request sent by a first device that has mutually passed security authentication, the negotiation probe request carrying the first device's first identifier and first probe request encrypted data, the first probe request encrypted data being generated by the first device using its master key based on its own first identifier and the result of a first counter; The first identifier is used to find the master key shared with the first device. If the corresponding master key is not found, a test error response is generated. Alternatively, if the corresponding master key is found, the first test request encrypted data is decrypted using the master key to obtain the result of the first counter. The result of the first counter is compared with the result of the second counter stored locally. If they are inconsistent, a test error response is generated. When a test error response is generated, the result of the second counter is reset to zero. A test error response is sent to the first device, so that after receiving the test error response, the first device resets the result of the first counter to zero and starts the key negotiation process of the first device; If the result of the first counter matches the result of the second counter stored locally, the second device generates and returns a successful test response to the first device, so that the first device increments the result of the first counter by one and does not start the key negotiation process of the first device.

[0057] In some embodiments, if the first plaintext used by the first device is generated based on the freshness value and the first preset certificate of the first device, after the second device decrypts to obtain the second plaintext, it verifies the freshness value. If the freshness value is valid, it calculates the certificate fingerprint of the first preset certificate and verifies whether the certificate fingerprint is in the whitelist. Otherwise, the second device refuses to connect.

[0058] Please see Figure 3 , Figure 3 This is an application architecture diagram of the lightweight secure communication method provided in this application embodiment. The first device is labeled MCU A, and the second device is labeled MCU B. MCU A and MCU B each have pre-installed certificates (pre-installed by the device manufacturer during the production phase), and each has a built-in whitelist of trusted MCU certificate fingerprints. Both MCU A and MCU B have a pre-shared key PSK. Through a key negotiation process, A and B achieve a shared master key MSK and verification key HSK.

[0059] MCU A first sends a negotiation request to MCU B. The negotiation request carries MCU A's first identifier and the first encryption parameter generated by MCU A based on the first random number and the pre-shared key.

[0060] After receiving the negotiation request, MCU B returns a negotiation response, which carries the second encryption parameters generated by the second device and the second identifier of MCU B.

[0061] MCU A receives the negotiation response from MCU B, decrypts the second encryption parameter to obtain the first random number and verifies its correctness. If the verification is correct, it uses the first and second random numbers to derive the master key and verification key. It encrypts the first plaintext using the master key to generate the first ciphertext, and obtains the first message authentication code of the first plaintext based on the hash function and the verification key. It then sends a negotiation verification request to MCU B, which carries the first ciphertext and the first message authentication code. After receiving the negotiation verification request, MCU B uses the first random number and the second random number to derive the master key and the verification key. It then decrypts the first ciphertext using the master key to generate the second plaintext. Based on the hash function and the verification key, it obtains the second message authentication code of the second plaintext. It compares the first message authentication code and the second message authentication code. If they match, it generates a negotiation verification response and sends the negotiation verification response to MCU A. MCU A receives the negotiation verification response.

[0062] In the communication process, the embodiments of this application reduce complex calculations through an efficient key negotiation process, thereby reducing the computational burden on the device and realizing lightweight secure communication.

[0063] Optionally, the lightweight secure communication method also includes a key negotiation probe process before the key negotiation process: MCU A sends a negotiation probe request to MCU B, which has already passed mutual security authentication. The negotiation probe request carries MCU A's first identifier and first probe request encrypted data. The first probe request encrypted data is generated by MCU A using its master key based on its own first identifier and the result of its first counter. After receiving the negotiation attempt request, MCU B searches for the master key shared with MCU B based on the first identifier. If the corresponding master key is not found, an attempt error signal is generated and returned. Alternatively, if the corresponding master key is found, the MCU B uses the master key to decrypt the encrypted data of the first attempt request, obtains the result of the first counter, and compares the result of the first counter with the result of the second counter stored locally. If they are inconsistent, an attempt error signal is generated and returned. When an attempt error signal is generated, MCU B resets the result of the second counter to zero. If MCU A receives a test error response, it resets the result of the first counter to zero and starts the key negotiation process; if it receives a test success response, it increments the result of the first counter by one and does not start the key negotiation process.

[0064] This application's embodiments incorporate a key negotiation probing process, avoiding repeated negotiation due to network latency, duplicate requests, or other reasons, thereby saving computing and network resources.

[0065] This application also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the lightweight secure communication method of any of the above embodiments.

[0066] This application also discloses a computer-readable storage medium storing a computer program that executes the lightweight secure communication method implementing any of the above embodiments.

[0067] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0068] The lightweight secure communication method, electronic device, and storage medium provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the concept of this application and should not be construed as limiting the scope of protection of this application.

Claims

1. A lightweight secure communication method, applied to a first device, characterized in that, The lightweight secure communication method includes a key negotiation process, which includes: A negotiation request is sent to a second device that has already passed mutual security authentication. The negotiation request carries the first identifier of the first device and the first encryption parameters generated by the first device based on a first random number and a pre-shared key. The second device receives a negotiation response, which carries a second identifier of the second device and a second encryption parameter generated by the second device. The second encryption parameter is generated by the second device by encrypting a first random number obtained by decrypting the first encryption parameter using the pre-shared key, a second random number selected by the second device, and the shared key. Decrypt the second encryption parameter to obtain the first random number and verify its correctness. If the verification is correct, then based on the first random number and the second random number, use key derivation to obtain the master key and the verification key; encrypt the first plaintext according to the master key to generate the first ciphertext, and obtain the first message authentication code of the first plaintext based on the hash function and the verification key. A negotiation verification request is sent to the second device. The negotiation verification request carries the first ciphertext and the first message authentication code, so that the second device can obtain a master key and a verification key based on the first random number and the second random number using key derivation, and decrypt the first ciphertext according to the master key to generate a second plaintext; obtain a second message authentication code of the second plaintext based on a hash function and the verification key; compare the first message authentication code and the second message authentication code, and if they match, generate a negotiation verification response; Receive the negotiation verification response returned by the second device.

2. The lightweight secure communication method according to claim 1, characterized in that, The lightweight secure communication method further includes a security authentication process before the key negotiation process; The security authentication process includes: The first device sends a first pre-configured certificate to the second device so that the second device can verify whether the first pre-configured certificate is in the whitelist. If it is in the whitelist, the security authentication of the first device is successful and an authentication success response is returned; otherwise, the second device refuses to connect. Receive the second pre-configured certificate sent by the second device, verify whether the second pre-configured certificate is in the whitelist. If it is in the whitelist, the security authentication of the second device is successful, and a successful authentication response is returned; otherwise, the connection is rejected.

3. The lightweight secure communication method according to claim 1, characterized in that, The key negotiation process also includes: A first counter is set for the second device, and the result of the first counter is sent to the second device so that the second device compares the result of the first counter with the result of a second counter stored locally. If they match, a verification success response is returned, and the result of the second counter is incremented by one, wherein the second counter is the counter set by the second device for the first device; if they do not match, a verification error response is returned, the result of the second counter is reset to zero, and the connection is rejected. If the first device receives the successful verification response, the result of the first counter is incremented by one; If the first device receives the verification error response, it resets the result of the first counter to zero and restarts the key negotiation process.

4. The lightweight secure communication method according to claim 3, characterized in that, The lightweight secure communication method further includes a key negotiation probe process before the key negotiation process. The key negotiation probing process includes: A negotiation attempt request is sent to a second device that has already passed mutual security authentication, so that the second device generates and returns a test error signal or a test success signal according to the negotiation attempt request; wherein the negotiation attempt request carries a first identifier of the first device and first test request encrypted data; the first test request encrypted data is generated by the first device using the master key based on its own first identifier and the result of the first counter; the test error response is generated and returned by the second device when it searches for the corresponding master key shared with the second device based on the first identifier, or when it does not find the corresponding master key, or, if the second device finds the corresponding master key, it decrypts the first test request encrypted data using the master key, obtains the result of the first counter, compares the result of the first counter with the result of the second counter stored locally, and generates and returns the first counter when they are inconsistent, and when the test error response is generated, the second device resets the result of the second counter to zero; the test success response is generated and returned by the second device when the result of the first counter is consistent with the result of the second counter stored locally. If the first device receives the probe error response, it resets the result of the first counter to zero and starts the key negotiation process; If the first device receives the successful probe response, it increments the result of the first counter by one and does not initiate the key negotiation process.

5. The lightweight secure communication method according to claim 1, characterized in that, The first plaintext is generated based on the freshness value and the first pre-set certificate of the first device, and the expression is: Data A =FV||CER A ; Among them, Data A First plaintext; FV is the freshness value, an identifier that can represent changes over time or continuous data updates; CER A This is the first pre-installed certificate for the first device; The first device sends a negotiation verification request to the second device, and the second device also decrypts the second plaintext and verifies the freshness value. If the freshness value is valid, the second device calculates the certificate fingerprint of the first pre-set certificate and verifies whether the certificate fingerprint is in the whitelist. Otherwise, the second device refuses to connect.

6. A lightweight secure communication method, applied to a second device, characterized in that, The lightweight secure communication method includes a key negotiation process, which includes: The system receives a negotiation request sent by a first device that has already mutually authenticated with the first device. The negotiation request carries a first identifier and a first encryption parameter of the first device. The first encryption parameter is generated by the first device through encryption based on a first random number and a pre-shared key. Decrypt the first encryption parameter to obtain a first random number, and encrypt the second encryption parameter based on the first random number, the second random number, and the pre-shared key; The negotiation response is sent to the first device, and the negotiation response carries the second identifier of the second device and the second encryption parameter, so that the first device can decrypt the first random number according to the second encryption parameter and verify whether it is correct. If the verification is correct, the first device uses the first random number and the second random number to derive the master key and the verification key; encrypts the first plaintext according to the master key to generate the first ciphertext, and obtains the first message authentication code of the plaintext based on the hash function and the verification key. Receive a negotiation verification request sent by the first device, wherein the negotiation verification request carries the first ciphertext and the first message authentication code; Based on the first random number and the second random number, a master key and a verification key are obtained using key derivation. The first ciphertext is decrypted using the master key to generate the second plaintext. A second message authentication code for the second plaintext is obtained based on a hash function and the verification key. The first message authentication code and the second message authentication code are compared. If they match, a negotiation verification response is generated. The negotiation verification response is sent to the first device.

7. The lightweight secure communication method according to claim 6, characterized in that, The key negotiation process also includes: A second counter is set for the first device, and the result of the second counter is sent to the first device so that the first device compares the result of the second counter with the result of the first counter stored locally. If they match, a verification success response is returned, and the result of the second counter is incremented by one, wherein the first counter is the counter set by the first device for the second device; if they do not match, a verification error response is returned, the result of the second counter is reset to zero, and the connection is rejected. If the second device receives the successful verification response, the result of the first counter is incremented by one; If the first device receives the verification error response, it resets the result of the first counter to zero and restarts the key negotiation process.

8. The lightweight secure communication method according to claim 7, characterized in that, The lightweight secure communication method further includes a key negotiation probe process before the key negotiation process. The key negotiation probing process includes: The system receives a negotiation probe request sent by the first device, which has already passed security authentication with the first device. The negotiation probe request carries the first device's first identifier and first probe request encrypted data. The first probe request encrypted data is generated by the first device using the master key based on its own first identifier and the result of the first counter. The system searches for the master key shared with the first device based on the first identifier. If the corresponding master key is not found, a test error response is generated. Alternatively, if the corresponding master key is found, the system uses the master key to decrypt the encrypted data of the first test request, obtains the result of the first counter, and compares the result of the first counter with the result of the second counter stored locally. If they are inconsistent, a test error response is generated. When the test error response is generated, the result of the second counter is reset to zero. The test error response is sent to the first device, so that after receiving the test error response, the first device resets the result of the first counter to zero and starts the key negotiation process of the first device; If the result of the first counter matches the result of the second counter stored locally, the second device generates and returns a successful test response to the first device, increments the result of the second counter by one, so that the first device increments the result of the first counter by one and does not initiate the key negotiation process of the first device.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the lightweight secure communication method according to any one of claims 1 to 5 or the lightweight secure communication method according to any one of claims 6 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the lightweight secure communication method according to any one of claims 1 to 5 or any one of claims 6 to 8.

Images