Secure communication method, network management controller, and electronic device

Abstract

The present disclosure relates to a secure communication method, a network management controller and an electronic device. The method comprises: establishing a first secure channel with an electronic device, wherein during establishment of the first secure channel, a first device terminal certificate of the electronic device is obtained; determining whether a device unique identifier written in the first device terminal certificate matches a hardware identity of the electronic device; in response to the device unique identifier matching the hardware identity of the electronic device, performing a cryptographic authentication key exchange with the electronic device via the first secure channel to generate a shared session key; and performing encrypted transmission of a communication packet with the electronic device based on the shared session key.

Description

Technical Field

[0001] This disclosure relates to the field of network management and communication security technology, and more specifically, to secure communication methods, network management controllers, and electronic devices. Background Technology

[0002] In a network management system, the network management controller (MDC) acts as the core control node, responsible for the unified configuration distribution, status monitoring, and policy enforcement of various electronic devices (referred to as managed devices) managed by the MDC. These electronic devices can include routers, switches, wireless access points, servers, and other network equipment. In a local deployment scenario, an instance of the MDC can be distributed to clients for local installation (e.g., on a local server) to run the MDC. Electronic devices can send discovery messages (e.g., via the User Datagram Protocol (UDP)). Upon receiving the discovery message, the MDC displays device information on its management interface, and then a connection is established for communication.

[0003] The security of communication between network management controllers and electronic devices is paramount. To ensure communication security, Transport Layer Security (TLS) is commonly used to establish secure connections. However, even with a secure connection, the true trustworthiness of both parties cannot be guaranteed. Attackers can still impersonate legitimate devices or controllers on the established secure channel, while electronic devices cannot verify whether the connected network management controller is a legitimate administrator, and the network management controller cannot verify whether the accessing electronic device is a genuine managed device.

[0004] Therefore, there is a need for a communication method that can reduce the risk of device counterfeiting in order to improve communication security. Summary of the Invention

[0005] In view of the above problems, this disclosure provides a secure communication method, a network management controller, and an electronic device. By establishing a secure channel and combining the verification of the electronic device's identity with the exchange of cryptographic authentication keys, it can achieve dual authentication of certificates and device identities, as well as dual encryption protection of the transport layer and the application, thereby reducing the risk of device forgery and improving communication security.

[0006] One aspect of this disclosure provides a secure communication method for a network management controller, comprising: establishing a first secure channel with an electronic device, wherein, during the establishment of the first secure channel, a first device terminal certificate of the electronic device is obtained; determining whether a unique device identifier written in the first device terminal certificate matches the hardware identity of the electronic device; in response to the matching of the unique device identifier with the hardware identity of the electronic device, performing a cryptographic authentication key exchange with the electronic device via the first secure channel to generate a shared session key; and performing encrypted transmission of communication messages with the electronic device based on the shared session key.

[0007] Another aspect of this disclosure provides a secure communication method for an electronic device, comprising: establishing a first secure channel with a network management controller, wherein, during the establishment of the first secure channel, a first device terminal certificate of the electronic device is sent to the network management controller; if the device unique identifier written in the first device terminal certificate of the electronic device matches the hardware identity of the electronic device, performing a cryptographic authentication key exchange with the network management controller via the first secure channel to generate a shared session key; and performing encrypted transmission of communication messages with the network management controller based on the shared session key.

[0008] Another aspect of this disclosure provides a network management controller, comprising: one or more processors; a memory coupled to at least one of the processors; and a set of computer program instructions stored in the memory, the set of computer program instructions executing the aforementioned secure communication method performed by the network management controller when executed by at least one of the processors.

[0009] Another aspect of this disclosure provides an electronic device comprising: one or more processors; a memory coupled to at least one of the processors; and a set of computer program instructions stored in the memory, the set of computer program instructions executing the above-described secure communication method performed by the electronic device when executed by at least one of the processors.

[0010] Another aspect of this disclosure provides a computer program product, including computer program instructions that, when executed by a processor, perform the aforementioned secure communication method. Attached Figure Description

[0011] The aspects, features, and advantages of this disclosure will become clearer and more readily understood from the following description of embodiments in conjunction with the accompanying drawings. The drawings are provided to offer a further understanding of the embodiments of this disclosure and form part of the specification. The drawings, together with the embodiments of this disclosure, are used to explain this disclosure but do not constitute a limitation thereof. In the drawings:

[0012] Figure 1 A schematic diagram illustrating a communication scenario between a network management controller and an electronic device according to various embodiments of the present disclosure is shown.

[0013] Figure 2 A schematic diagram illustrating an example implementation of a secure communication method according to various embodiments of the present disclosure is shown.

[0014] Figure 3 A schematic diagram of another example implementation of a secure communication method according to various embodiments of the present disclosure is shown.

[0015] Figure 4 A flowchart illustrating a secure communication method performed by a network management controller according to various embodiments of the present disclosure is shown.

[0016] Figure 5 A flowchart illustrating a secure communication method performed by an electronic device according to various embodiments of the present disclosure is shown.

[0017] Figure 6 Example block diagrams of network management controllers according to various embodiments of the present disclosure are shown.

[0018] Figure 7 Example block diagrams of electronic devices according to various embodiments of the present disclosure are shown. Detailed Implementation

[0019] The technical solutions of this disclosure will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the protection scope of this disclosure.

[0020] Furthermore, the technical features involved in the different embodiments of this disclosure described below can be combined with each other as long as they do not conflict with each other.

[0021] The terms “exemplary” and / or “example” are used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” and / or “example” is not necessarily to be construed as superior to or better than other aspects. Similarly, the term “aspects of this disclosure” does not require that all aspects of this disclosure include the features, advantages, or modes of operation discussed.

[0022] In locally deployed scenarios, network management controller instances typically use a unified self-signed certificate and corresponding private key for authentication of electronic devices. The private key is hard-coded into the code and distributed to all clients. Therefore, if the private key is leaked due to decompilation, all deployed instances will be compromised simultaneously. Attackers can use this private key to decrypt or tamper with communication traffic, carrying out a man-in-the-middle attack (MITM), which has an impact on all clients and poses an extremely high risk.

[0023] To address the issues caused by self-signed certificates, some solutions have proposed allowing users to upload their own certificates. The basic idea is that users issue certificates using their own Certificate Authority (CA) and upload the certificate and corresponding private key to the network management controller, replacing the built-in default certificate. This achieves differentiated deployment of certificates across different network management controllers, resolving the problems caused by using the same set of certificates and private keys. However, this solution relies on user intervention, requiring users (e.g., network administrators) to manually generate CA root certificates, issue server certificates to the network management controller, and correctly configure the certificate chain. These operations require users to have relatively systematic public key infrastructure expertise, which most users (e.g., network administrators) lack. In actual deployment, the complexity of the steps and the numerous configuration details often lead to certificate configuration errors, introducing new security risks and even causing communication interruptions between the controller and electronic devices. Furthermore, while this solution allows the network management controller to prove it possesses a unique private key to electronic devices, it cannot verify the legitimacy of the electronic devices. Attackers can use methods such as forging device certificates to impersonate legitimate electronic devices to access the network management controller and carry out malicious operations such as information theft. Therefore, this improvement plan still poses significant security risks.

[0024] In addition to the improvements mentioned above, the standard Mutual TLS (mTLS) scheme can also be used. The mTLS scheme requires both communicating parties to verify each other's digital certificates during the TLS handshake phase to ensure the authenticity of the other party's identity. The mTLS scheme is widely used in areas such as web services, typically relying on certificates issued by public CAs or an enterprise's internal Public Key Infrastructure (PKI) system for certificate issuance and management. In the mTLS scheme, during the handshake phase, both communicating parties not only need to verify the legitimacy of the other party's certificate but also need to use their respective certificate's private keys to participate in session key negotiation, generating a session key used to encrypt subsequent communication content. Therefore, the security of the TLS layer depends entirely on the confidentiality of the certificate's private key. However, if the certificate's private key is stored in a hard-coded, weakly encrypted, or unencrypted form, attackers can obtain it through decompilation or other means. Once the certificate's private key is leaked, attackers can decrypt captured historical communication records or intercept and decrypt subsequent communication content in real time, completely compromising the security of the TLS channel. Furthermore, the mTLS scheme focuses on security protection at the transport layer but does not provide additional security protection for application layer data transmitted through the TLS channel itself, lacking defense-in-depth capabilities. The leakage of certificate private keys can lead to security risks to application layer data.

[0025] Based on this, this disclosure proposes a mechanism that combines a secure channel for the transport layer with a cryptographic authentication key exchange for the application layer, enabling dual authentication and dual encryption protection for electronic devices and network management controllers. Specifically, a secure channel is established at the transport layer, and then a cryptographic authentication key exchange is performed via the secure channel to generate a shared session key. The shared session key is then used to encrypt and transmit communication messages at the application layer.

[0026] Figure 1 A schematic diagram of a communication scenario 100 between a network management controller and an electronic device according to various embodiments of the present disclosure is shown.

[0027] In such Figure 1 In the communication scenario 100 shown, there may be one or more network management controllers 110 and one or more electronic devices 120. The network management controller 110, as the core control node, is responsible for unified configuration distribution, status monitoring, and policy enforcement for various electronic devices. The electronic devices 120 may include network devices such as routers, switches, wireless access points, and servers. Typically, the network management controller 110 can perform one-way or two-way TLS authentication with the electronic devices 120 to establish a TLS secure channel. For example, self-signed certificate schemes and mTLS schemes, as mentioned above, are easily decompiled by attackers to obtain private keys, thereby enabling man-in-the-middle attacks.

[0028] Figure 2 The illustration shows an example implementation of a secure communication method according to various embodiments of the present disclosure. It is understood that the steps in this example may be omitted, added, or rearranged as needed, and it is not necessary to strictly follow the entire process or include all details.

[0029] According to various embodiments of this disclosure, a secure channel can be established between electronic device 210 and network management controller 220. For example, the secure channel can be established based on Transport Layer Security (TLS), and therefore, the secure channel can also be referred to as a TLS secure channel. During the TLS handshake process, the two parties can, for example, negotiate a temporary, shared session key specific to the current connection based on publicly available parameters using algorithms such as Diffie-Hellman key exchange. This key is used to encrypt subsequent communication data to achieve the function of a secure channel, i.e., transport layer encryption. After completing the TLS handshake, a secure channel, also referred to as a TLS secure channel, can be established. The TLS handshake process may include certificate verification (e.g., the aforementioned TLS mutual authentication) to verify the legitimacy of the peer's certificate. Those skilled in the art should understand that the protocols used in this disclosure for establishing secure channels are not limited to the TLS protocol, but may also include other protocols capable of establishing secure channels.

[0030] According to various embodiments of this disclosure, a certificate chain verification method can be used to verify the device certificate of electronic device 210. For example, a three-level Device Attestation Certificate (DAC) certificate chain mechanism can be used. The first level is the root certificate, which can serve as a trust anchor for certificate issuance and unified management. The private key of the root certificate is protected by offline storage or hardware-level isolation to ensure zero risk of private key leakage and safeguard the foundational security of the entire trust chain. The second level is the intermediate certificate, which is signed and issued by the private key of the root certificate and is used for access control and risk management. When the intermediate certificate key is leaked, it can be quickly revoked and reissued without affecting the stability of the root certificate. The third level is the device terminal certificate, which is signed and issued by the private key of the intermediate certificate and deployed on each electronic device. Figure 2 As shown, in step S1, the network management controller 220 can pre-configure a trusted root certificate at the factory or during the software deployment phase 8. In step S2, the electronic device 210 can send its device certificate (which may include an intermediate certificate and a device endpoint certificate) to the network management controller 220. In step S3, the network management controller 220 can use the pre-configured trusted root certificate to verify the device certificate of the electronic device 210. For example, the pre-configured trusted root certificate can be used to verify the signature of the intermediate certificate, and then the intermediate certificate can be used to verify the signature of the device endpoint certificate. This certificate chain verification method ensures that the certificate chain is completely and effectively traced back to the trusted root certificate. Figure 2 Only the certificate verification process of network management controller 220 to electronic device 210 is shown. For the sake of brevity, the certificate verification process of electronic device 210 to network management controller 220 is not shown. The latter can use a conventional certificate verification process.

[0031] According to various embodiments of this disclosure, in step S4, the network management controller 220 can verify the identity information of the electronic device 210. For example, a unique device identifier can be written (or burned) into the device terminal certificate of the electronic device 210. The network management controller 220 can read the unique device identifier written in the device terminal certificate and compare it with the identity information of the current device to determine whether the unique device identifier and the identity information of the current device match. The identity information can refer to hardware identity. For example, a double decryption comparison can be performed in the cloud to determine whether the unique device identifier and the identity information of the current device match. If the unique device identifier matches the identity information of the current device, it can be confirmed that the device terminal certificate does indeed belong to the current device. If the unique device identifier does not match the identity information of the current device, it can be confirmed that the device terminal certificate does not belong to the current device, and the current device may have stolen the device terminal certificate and the corresponding private key, and intends to impersonate the real device to establish a connection with the network management controller 220. The unique device identifier can be embedded in the certificate extension field of the device terminal certificate. The unique device identifier may include a Media Access Control (MAC) address. Existing IoT standards (such as the Matter protocol and other general IoT standards) include DAC certificates containing vendor IDs (VIDs) or product IDs (PIDs) indicating the same batch or model of devices. Therefore, these certificates are susceptible to spoofing or replay attacks. As mentioned above, both the mTLS scheme and the user-uploaded certificate scheme only authenticate the certificate; the certificate is not bound to a unique device identifier. Therefore, they cannot prevent certificate cloning attacks.

[0032] In this way, by forcibly binding the certificate to the physical identity of the electronic device (e.g., MAC address) and comparing the current device's identity, the legitimacy of the certificate no longer depends solely on whether a valid private key is possessed. Instead, it requires that the physical identity bound to the certificate match the hardware identity of the current communication peer, thereby fundamentally blocking device spoofing attacks implemented through certificate duplication. Even if an attacker obtains a legitimate certificate, the corresponding private key, and all materials of the certificate chain, if the device's hardware identity does not match, authentication on the controller side will still fail.

[0033] After a secure channel is established, in response to the successful authentication of electronic device 210, electronic device 210 and network management controller 220 can perform a password-authenticated key exchange to generate a shared session key. Password-authenticated key exchange refers to the process of authenticating identity via password and securely generating a high-strength session key. Therefore, the password-authenticated key exchange process is brute-force resistant and non-replayable. Password-authenticated key exchange can be based on a password-authenticated key exchange protocol (PAKE), including protocols such as SPAKE2, SPAKE2+, Secure Remote Password Protocol (SRP), and Encrypted Key Exchange (EKE). SPAKE2+, in particular, due to its strong security, can be applied to scenarios with extremely high security requirements, such as Matter protocol smart homes.

[0034] For example, password authentication key exchange may include an offline registration phase and an authentication phase. Network management controller 220 acts as the prover, and electronic device 210 acts as the verifier. In the offline registration phase, in step S5, the user can register a user password (e.g., "123456") on network management controller 220. In step S6, network management controller 220 can calculate a derived value w from the registered user password. For example, the plaintext password and other parameters are calculated using a hash algorithm (e.g., MD5, SHA-1) to produce a fixed-length hash string as the derived value w. The derived value w is irreversibly computed. Irreversible computation means that the original user password (e.g., "123456") cannot be recovered in reverse, thus preventing an attacker from knowing the user password even if they obtain the derived value. For example, irreversible computation may include elliptic curve product calculation. For example, for SPAKE2+, two derived values ​​w0 and w1 can be generated. Then, in step S7, the network management controller 220 can send the derived value w (e.g., w0 for SPAKE2+) to the electronic device 210 via the established secure channel. The derived value w can be stored in the electronic device 210 for subsequent consistency verification. Sending the derived value instead of the user password itself to the electronic device ensures that only the network management controller 220 knows the user password and that it cannot be stolen by an attacker, thereby improving password security.

[0035] During the authentication phase (e.g., the SPAKE2+ four-way handshake process), in step S8, electronic device 210 can generate a temporary public key K1 based on a derived value w and a random number x. In step S8', network management controller 220 can generate a temporary public key K2 based on a derived value w' and a random number y. The derived value w' can be generated by network management controller 220 calculating the user password entered on network management controller 220, and its generation process is the same as that of derived value w. The purpose of the password authentication key exchange is to prove that the entered user password is the same as the registered user password (e.g., "123456"). If the entered user password is the same as the registered user password (e.g., "123456"), then the derived value w can be the same as the derived value w'; otherwise, they are different. The random numbers x and y are generated independently by each party locally and are not transmitted in plaintext or decryptable form in any message. Instead, the calculated temporary public key is transmitted. Even if an attacker intercepts the temporary public key, they cannot obtain the random number, thus effectively preventing replay attacks.

[0036] In step S9, the electronic device 210 and the network management controller 220 may exchange temporary public keys. Specifically, the electronic device 210 sends the temporary public key K1 to the network management controller 220, and the network management controller 220 sends the temporary public key K2 to the electronic device 210.

[0037] Electronic device 210 and network management controller 220 can perform consistency verification based on temporary public key K1 and temporary public key K2 to complete the exchange of cryptographic authentication keys. For example, the consistency verification process may include steps S10-S14, which are only specific examples and are not limited thereto. The consistency verification process can also use other verification methods with cryptographic strength, as long as it can confirm that the passwords of both parties are consistent based on the public key. In step S10, electronic device 210 can calculate authentication code C1 based on temporary public key K2 and generate session key K. shared The authentication code can also be called the confirmation value. For example, electronic device 210 can use a key derivation function to generate a confirmation key K based on the temporary public key K2. confirmV and session key K shared It uses the Message Authentication Code (MAC) algorithm based on the confirmation key K. confirmV Calculate the authentication code C1 using the temporary public key K2. For example, C1 = MAC(K2). confirmV In step S10', the network management controller 220 can calculate the authentication code C2 based on the temporary public key K1 and generate the session key K. shared For example, the network management controller 220 can use a key derivation function to generate an acknowledgment key K based on the temporary public key K1.confirmP and session key K shared And use the MAC algorithm based on the confirmation key K confirmP Calculate the authentication code C2 using the received temporary public key K1. For example, C2 = MAC(K1 + K2 ... confirmP , K1).

[0038] In step S11, the network management controller 220 can send the authentication code C2 to the electronic device 210. In step S12, the electronic device 210 can perform consistency verification on the authentication code C2. For example, the electronic device 210 can generate a confirmation key K based on the temporary public key K1 in the same way. confirmP The system calculates authentication code C2' and then determines whether the calculated authentication code C2' matches the received authentication code C2. If the calculated authentication code C2' matches the received authentication code C2, the consistency verification of authentication code C2 is considered successful; otherwise, it fails.

[0039] In step S13, the electronic device 210 can send the authentication code C1 to the network management controller 220. In step S14, the network management controller 220 can perform consistency verification on the authentication code C1. For example, the network management controller 220 can generate a confirmation key K based on the temporary public key K2 in the same way. confirmV The system calculates the authentication code C1' and then determines whether the calculated authentication code C1' matches the received authentication code C1. If the calculated authentication code C1' matches the received authentication code C1, the consistency verification of authentication code C1 is considered successful; otherwise, it fails.

[0040] For example, such as Figure 2 As shown, authentication code C2 can be sent to electronic device 210 for consistency verification before authentication code C1 is sent to network management controller 220. In response to the failure of consistency verification of authentication code C2, the failure counter at electronic device 210 increments, and in response to the failure counter exceeding a predetermined threshold, electronic device 210 can determine that the verification operation (e.g., password authentication key exchange) is locked (i.e., prohibited) for a predetermined period of time (e.g., 10 minutes, 30 minutes, or longer). In other words, the user cannot re-enter the password within the predetermined period to try again. This effectively prevents attackers from brute-forcing passwords through repeated trial and error and reduces the efficiency of attackers' attempts.

[0041] When authentication codes C1 and C2 pass consistency verification, the key confirmation process (i.e., password authentication key exchange) is completed, and the session key K generated during this process can be used. shared The session key is determined to be shared. Assuming both parties use the same authentication code, the session key K is typically calculated by both parties. sharedIt's the same.

[0042] This disclosure, by employing cryptographic authentication key exchange (e.g., SPAKE2+), enables two-way authentication and secure key negotiation with strong robustness, without relying on public key infrastructure (PKI) and digital certificate systems, and without being subject to man-in-the-middle (MITM) attacks.

[0043] In step S15, secure communication can be performed between electronic device 210 and network management controller 220 based on a shared session key. For example, electronic device 210 and network management controller 220 can perform encrypted transmission of communication messages (which can be interchanged with communication data, service data, etc.) based on the shared session key. Specifically, electronic device 210 and network management controller 220 can both use the shared session key K. shared Application-layer encryption is applied to communication messages. The receiver can use the shared session key K. shared Decrypt encrypted communication messages. Alternatively, the shared session key K can be used without directly employing it. shared Instead, it uses the shared session key K. shared (For example, through a key derivation function) A temporary encryption key is derived to encrypt communication messages at the application layer. The receiver can decrypt the encrypted communication messages using a temporary decryption key derived in the same way (which is usually symmetric to the temporary encryption key).

[0044] Through the above process, based on the transport layer secure channel, and through the shared session key K... shared The communication messages are encrypted twice, and an independent security barrier is built at the application layer, which effectively resists network eavesdropping, tampering and replay attacks, and ensures the confidentiality (leakage prevention) and integrity (forgery prevention) of data in insecure channels.

[0045] Furthermore, random numbers x and y can be generated each time a secure channel is established. Since the generated random numbers may be different each time, this ensures that the temporary public key and shared session key (i.e., K) generated each time are consistent. shared The encryption of a session is also different and unpredictable. Therefore, even if an attacker obtains encrypted messages from a particular session through eavesdropping, they cannot replay them in a newly established session. In this way, the security risk of replay attacks can be fundamentally eliminated without maintaining an additional anti-replay mechanism.

[0046] Therefore, this disclosure combines application-layer cryptographic authentication key exchange with a transport layer secure channel to achieve dual authentication and dual encryption at both the transport and application layers. Even if an attacker breaks the transport layer authentication (e.g., steals a TLS certificate), they cannot bypass hardware authentication and user password authentication (i.e., cryptographic authentication key exchange) to impersonate a legitimate identity. This dual authentication significantly improves the robustness of the defense. Furthermore, based on the secure channel (which is equivalent to one encryption step), the shared session key generated by the cryptographic authentication key exchange performs a second encryption on the communication messages. This dual encryption constructs a deep and complete security chain from network layer access and application layer authentication to full lifecycle data protection.

[0047] Furthermore, compared to the mechanism of first establishing a temporary encrypted channel using a low-entropy password (e.g., SPAKE2+) and then verifying the device certificate (e.g., DAC), this disclosure employs a handshake process established using a secure channel to perform certificate verification first, and embeds physical identity binding verification (i.e., strongly binding the device certificate with the device's unique identifier and verifying the device's identity) into the handshake phase or immediately following it to achieve dual verification of "certificate + physical hardware." Only after the "certificate + physical hardware" verification is successful can the reverse mechanism of the application layer cryptographic authentication key exchange process (which may be a complex and energy-intensive process) be triggered. In this way, this disclosure can filter out counterfeit devices at an early stage through "certificate + physical hardware" verification, preventing them from entering subsequent stages. This prevents attackers from deceiving the network management controller in subsequent session flows through any physical layer substitution means, thereby eliminating RF relay and timing hijacking attacks at the root and effectively filling the defense gap in existing general IoT standards against physical layer interaction hijacking.

[0048] Furthermore, this disclosure uses a cascaded DAC certificate chain to verify the hardware identity of the device, confirming its authenticity and legitimacy from the perspectives of production source and brand compliance. Simultaneously, based on cryptographic authentication key exchange, it verifies the ownership of the user holding the physical network configuration code, confirming that the user has legitimate permissions to the device. These two authentication paths are logically independent and completely decoupled, verifying two different dimensions of security attributes: "whether the device is a genuine and legitimate device" and "whether the user is a legitimate holder." Failure in either dimension results in denial of device access, effectively resisting security threats such as device forgery and identity impersonation, and significantly improving the overall security robustness of device access authentication in network device management scenarios.

[0049] Figure 3 A schematic diagram of another example implementation of a secure communication method according to various embodiments of the present disclosure is shown. It is understood that the steps in this example may be omitted, added, or rearranged as needed, and it is not necessary to strictly follow the entire process or include all details.

[0050] Figure 3 The example implementation process shown is the same as Figure 2 The difference between the example implementations lies in the secure communication phase. Figure 3 The example implementation shown does not directly use the shared session key K. shared Alternatively, instead of using a temporary encryption key to encrypt communication messages at the application layer, a shared session key K is utilized. shared A new secure channel is established using temporary credentials, and a new shared session key is renegotiated based on this new secure channel. Then, application-layer encryption is applied to the communication messages using the new shared session key. In other words, Figure 3 The example implementation process shown is not executed. Figure 2 Instead of step S15 as shown, perform... Figure 3 Steps S16 to S23 are shown below. For the sake of brevity, Figure 2 Steps S1 to S14 are applicable here and will not be elaborated further. Figure 3 The illustrations for steps S1 to S14 are also omitted.

[0051] After completing the cryptographic authentication key exchange, in step S16, the network management controller 220 can create a new device certificate chain for the electronic device 210. The new device certificate chain may include a CA root certificate, a second device terminal certificate, and a device private key. In step S17, the shared session key K described above is used... shared Or based on the shared session key K shared The derived temporary encryption key is used to apply layer encryption to the new device certificate chain. Then, in step S18, via a previously established secure channel (such as...) Figure 2 The secure channel 1) shown sends an encrypted new device certificate chain to electronic device 210. Upon receiving the encrypted new device certificate chain, electronic device 210 can obtain the new device certificate chain. For example, electronic device 210 can obtain the new device certificate chain based on the shared session key K described above. shared Or based on the shared session key K shared The derived temporary decryption key is used to decrypt the encrypted new device certificate chain in order to obtain the new device certificate chain. Electronic device 210 can store the new device certificate chain locally.

[0052] After the transmission is complete, the previously established secure channel can be disconnected (e.g., Figure 2 As shown in security passage 1). Then, you can begin establishing new security passages (such as...). Figure 3(See secure channel 2). For example, a new handshake (e.g., a TLS handshake) for establishing a secure channel can be triggered when a previous secure channel is disconnected. The new handshake can be a fast TLS handshake. A fast TLS handshake can reuse the negotiated parameters of the previous TLS connection in the new TLS handshake to skip some operations, thereby reducing the number of communication round trips at the protocol level and improving communication efficiency. Furthermore, the shared session key K can be released. shared Temporary encryption keys and temporary decryption keys are used to promptly release memory and prevent replay attacks. Steps S16 to S19 above can be considered as the preparation phase for establishing a new secure channel.

[0053] During the establishment phase of a new secure channel (e.g., during a fast TLS handshake), electronic device 210 can sign the second device terminal certificate using its device private key. In step S20, the newly signed device certificate chain can be sent to network management control 220 for verification. In step S21, network management control 220 can verify the validity of the new device certificate chain sent by electronic device 210. For example, network management control 220 can first verify the legitimacy of the second device terminal certificate using a pre-set CA root certificate (e.g., whether it has been tampered with, expired, or issued by itself), and can use the public key in the pre-set CA root certificate to verify the signature on the second device terminal certificate. As long as the signature verification is successful, network management control 220 can determine that the other party is the legitimate holder of the second device terminal certificate, thereby preventing impersonation by a middleman.

[0054] In step S22, the TLS handshake process can be completed to successfully establish a new secure channel. During the TLS handshake, both parties can negotiate a temporary, shared session key K' specific to the current connection based on public parameters, for example, through algorithms such as Diffie-Hellman key exchange. shared It is used to encrypt subsequent communication data in order to achieve the function of a secure channel.

[0055] In step S23, electronic device 210 and network management controller 220 can communicate on a new secure channel based on a new shared session key K'. shared Perform secure communication. For example, electronic device 210 and network management controller 220 can perform secure communication based on a new shared session key K'. shared Or by a new shared session key K' shared (For example, through a key derivation function) a temporary encryption key is derived to encrypt communication messages transmitted over a new secure channel.

[0056] This shows that, Figure 3 In the example implementation, Figure 2Based on the example implementation process, the shared session key K is utilized. shared Establishing a new secure channel using temporary credentials ensures that even if the key of the old session or the private key of the old certificate is cracked, attackers will not be able to decrypt the communication data in the newly established connection, thus further improving security.

[0057] Figure 4 Various embodiments of the network management controller (e.g., such as) according to this disclosure are shown. Figure 1 The network management controller 110 and shown Figure 2 and Figure 3 The flowchart shows the secure communication method 400 executed by the network management controller 220.

[0058] In step S410, the network management controller can communicate with electronic devices (e.g., such as...) Figure 1 The electronic device 120 shown and Figure 2 and Figure 3 The electronic device 210 shown establishes a first secure channel (e.g., Figure 2 The first secure channel is shown as 1). During the establishment of the first secure channel, the first device terminal certificate of the electronic device is obtained.

[0059] For example, a three-level Device Authentication Certificate (DAC) certificate chain mechanism can be employed. For instance, during the establishment of the first secure channel (e.g., during the handshake), the network management controller can receive a first device certificate chain from the electronic device. The first device certificate chain may include a first device endpoint certificate (which is third level) and a first intermediate certificate (which is second level). The first intermediate certificate can be verified using a trusted root certificate pre-installed on the network management controller, and the first device endpoint certificate can be verified using the first intermediate certificate. Specifically, the root certificate (which is first level) can be used to issue the first intermediate certificate; therefore, the root certificate can be used to verify the correctness of the signature on the first intermediate certificate. The first intermediate certificate can be used to issue the first device endpoint certificate; therefore, the first intermediate certificate can be used to verify the correctness of the signature on the first device endpoint certificate. For example, the network management controller may pre-install a trusted root certificate during the factory or software deployment phase. The network management controller can receive a first device certificate chain (which may include a first intermediate certificate and a first device endpoint certificate) from the electronic device. The network management controller can use the pre-installed trusted root certificate to verify the signature of the first intermediate device certificate of the electronic device, and then use the first intermediate certificate to verify the signature of the first device endpoint certificate. This certificate chain verification method ensures that the certificate chain is completely and effectively traceable to the trusted root certificate. Then, once the first device's certificate chain is verified, both parties can establish a first secure channel.

[0060] For example, the first secure channel can be established based on the Transport Layer Security (TLS) protocol; therefore, the first secure channel can also be called a TLS secure channel. During the TLS handshake process, both parties can, for example, negotiate a temporary, shared session key specific to the current connection based on publicly available parameters using algorithms such as Diffie-Hellman key exchange. This key is used to encrypt subsequent communication data to achieve the function of a secure channel. Those skilled in the art should understand that the protocols used in this disclosure for establishing secure channels are not limited to the TLS protocol, but may also include other protocols capable of establishing secure channels.

[0061] In step S420, the network management controller can determine whether the device unique identifier written in the first device terminal certificate matches the hardware identity of the electronic device. For example, the device unique identifier can be written (or burned) into the first device terminal certificate of the electronic device. For example, the media access control (MAC) address of the electronic device can be written as the device unique identifier into the first device terminal certificate. For example, the device unique identifier can be embedded in the certificate extension field of the first device terminal certificate. The network management controller can read the device unique identifier written in the first device terminal certificate and compare it with the identity information of the current device (e.g., hardware identity) to determine whether the device unique identifier and the identity information of the current device match. For example, a double decryption comparison can be performed in the cloud to determine whether the device unique identifier and the identity information of the current device match. If the device unique identifier matches the identity information of the current device, it can be confirmed that the device terminal certificate does indeed belong to the current device. If the device unique identifier does not match the identity information of the current device, it can be confirmed that the device terminal certificate does not belong to the current device. In addition, the process of verifying the identity of the electronic device 210 can be carried out during the TLS handshake phase or immediately after the establishment of the TLS secure channel.

[0062] In step S430, the network management controller may, in response to the matching of the device's unique identifier with the electronic device's hardware identity, perform a cryptographic authentication key exchange with the electronic device via a first secure channel to generate a shared session key. The cryptographic authentication key exchange may be based on a cryptographic authentication key exchange protocol (PAKE), including, for example, SPAKE2, SPAKE2+, Secure Remote Cryptography Protocol (SRP), and Encryption Key Exchange (EKE).

[0063] In the process of cryptographic key exchange, the network management controller can act as the prover, and the electronic device can act as the verifier. The cryptographic key exchange performed at the network management controller may include: generating a first temporary public key (temporary public key K2 as described above) based on a first derived value (derived value w' as described above) and a first random number (random number y as described above); exchanging the first temporary public key (temporary public key K2 as described above) and a second temporary public key (temporary public key K1 as described above) generated by the electronic device via a first secure channel; and performing consistency verification based on the first temporary public key (temporary public key K2 as described above) and the second temporary public key (temporary public key K1 as described above) to complete the cryptographic key exchange. The second temporary public key (temporary public key K1 as described above) is generated based on a second derived value (derived value w as described above) and a second random number (random number x as described above). The first derived value (the derived value w' as described above) can be a value generated by irreversibly calculating the user password entered on the network management controller, and the second derived value (the derived value w as described above) can be a value generated by irreversibly calculating the user password registered during password registration. For example, irreversible calculation can include elliptic curve product calculation. Furthermore, the first and second random numbers can be generated each time a secure channel is established.

[0064] During the offline registration phase, a user can register a user password (e.g., "123456") on the network management controller. The network management controller can calculate a second derived value (derived value w as described above) from the registered user password. The network management controller can then send the second derived value (derived value w as described above) to an electronic device via an established secure channel. The second derived value (derived value w as described above) can be stored in the electronic device for subsequent consistency verification.

[0065] For example, the consistency verification process may include steps S10-S14 as described above. These steps are only a specific example and are not limited to them. The consistency verification process can also employ other cryptographically strong verification methods, as long as the consistency of the passwords of both parties can be confirmed based on the public key. The network management controller can use the Message Authentication Code (MAC) algorithm to calculate the first authentication code (authentication code C2 as described above) based on the received second temporary public key (temporary public key K1 as described above) and generate the session key K. shared For example, the network management controller can use a key derivation function to generate an acknowledgment key K based on the received second temporary public key (the temporary public key K1 as described above). confirmP and session key K shared And use the MAC algorithm based on the confirmation key K confirmPCalculate the first authentication code (authentication code C2 as described above) using the received second temporary public key (temporary public key K1 as described above). For example, C2 = MAC(K1). confirmP , K1).

[0066] Then, the network management controller can send the first authentication code (authentication code C2 as described above) to the electronic device for consistency verification. For example, electronic device 210 can generate a confirmation key K based on the second temporary public key (temporary public key K1 as described above) in the same manner. confirmP The system calculates a third authentication code (authentication code C2' as described above), and then determines whether the calculated third authentication code (authentication code C2' as described above) matches the received first authentication code (authentication code C2 as described above). In response to the determination that the calculated third authentication code (authentication code C2' as described above) matches the received first authentication code (authentication code C2 as described above), the consistency verification of the first authentication code (authentication code C2 as described above) is successful; otherwise, it fails.

[0067] The network management controller can receive a second authentication code (authentication code C1 as described above) from the electronic device. The network management controller can then perform a consistency verification on the second authentication code (authentication code C1 as described above) received from the electronic device. The second authentication code (authentication code C1 as described above) can be calculated by the electronic device using a Message Authentication Code (MAC) algorithm based on a first temporary public key (temporary public key K2 as described above). For example, the electronic device can use a key derivation function to generate a confirmation key K based on the received first temporary public key (temporary public key K2 as described above). confirmV and session key K shared And use the MAC algorithm based on the confirmation key K confirmV Calculate the second authentication code (authentication code C1 as described above) using the received first temporary public key (temporary public key K2 as described above). For example, C1 = MAC(K2). confirmV For example, the network management controller can generate an acknowledgment key K based on the first temporary public key (the temporary public key K2 as described above) in the same way. confirmV The system calculates a fourth authentication code (authentication code C1' as described above), and then determines whether the calculated fourth authentication code (authentication code C1' as described above) matches the received second authentication code (authentication code C1 as described above). In response to the determination that the calculated fourth authentication code (authentication code C1' as described above) matches the received second authentication code (authentication code C1 as described above), the consistency verification of the second authentication code (authentication code C1 as described above) is successful; otherwise, it fails.

[0068] For example, the first authentication code (authentication code C2 as described above) can be sent to the electronic device for consistency verification before the second authentication code (authentication code C1 as described above) is sent to the network management controller. In response to the failure of consistency verification of the first authentication code (authentication code C2 as described above), the failure counter at the electronic device is incremented, and in response to the value of the failure counter exceeding a predetermined threshold, the electronic device can determine to lock (i.e., prohibit) the verification operation for a predetermined period of time (e.g., 10 minutes, 30 minutes, or longer).

[0069] When the consistency verification based on the first authentication code (authentication code C2 as described above) and the second authentication code (authentication code C1 as described above) is successful, the key confirmation process (i.e., password authentication key exchange) can be completed, and the generated session key K can be transferred. shared It has been determined to be a shared session key.

[0070] In step S440, the network management controller can perform encrypted transmission of communication messages with electronic devices based on a shared session key.

[0071] In one embodiment, such as Figure 2 As shown in step S15, the network management controller can use the shared session key K shared Alternatively, application-layer encryption can be applied to the communication messages using a temporary encryption key derived from a shared session key (e.g., via a key derivation function). The network management controller can then transmit the encrypted communication messages to the electronic devices via the first secure channel.

[0072] In another embodiment, such as Figure 3As shown in steps S16-S23, the network management controller can create a second device certificate chain for the electronic device. The second device certificate chain may include a root certificate, a second device terminal certificate, and a device private key. The network management controller can use a shared session key or a temporary encryption key derived from the shared session key (e.g., through a key derivation function) to perform application-layer encryption on the second device certificate chain. The network management controller can send the encrypted second device certificate chain to the electronic device via a first secure channel. The network management controller can verify the received second device terminal certificate signed by the electronic device. For example, the network management controller can first verify the validity of the second device terminal certificate using a pre-set CA root certificate, and can then use the public key in the pre-set CA root certificate to verify the signature on the second device terminal certificate. Based on the verification result (i.e., verification passed), the network management controller can establish a second secure channel with the electronic device. The first secure channel can be disconnected before or simultaneously with the establishment of the second secure channel. For example, a new handshake (e.g., a TLS handshake) for establishing the second secure channel can be triggered when the first secure channel is disconnected. The new handshake can be a fast TLS handshake. After establishing the second secure channel, the network management controller can transmit communication messages with the electronic device via the second secure channel. During the handshake process of establishing a second secure channel, both parties can negotiate a temporary, shared session key K' specific to the current connection based on public parameters, for example, through algorithms such as Diffie-Hellman key exchange. shared This is used to encrypt subsequent communication data. The network management controller can then use the new shared session key K'. shared Or by a new shared session key K' shared (For example, through a key derivation function) a temporary encryption key is used to encrypt communication messages transmitted over a second secure channel.

[0073] For the sake of brevity, please refer to the above for specific details. Figure 2 and Figure 3 The description will not be repeated here.

[0074] Figure 5 Various embodiments of the present disclosure are illustrated using electronic devices (e.g., such as...) Figure 1 The electronic device 120 shown and Figure 2 and Figure 3 The flowchart shows the secure communication method 500 executed by the electronic device 210 shown.

[0075] In step S510, the electronic device can communicate with the network management controller (e.g., such as...) Figure 1 The network management controller 110 and shown Figure 2 and Figure 3The network management controller 220 shown establishes a first secure channel. During the establishment of the first secure channel (e.g., during a TLS handshake), the electronic device may send its first device endpoint certificate to the network management controller.

[0076] For example, a three-tier Device Authentication Certificate (DAC) certificate chain mechanism can be used. Electronic devices can send their first device certificate chain to the network management controller. The first device certificate chain can include a first device endpoint certificate (which is the third level) and a first intermediate certificate (which is the second level). The first intermediate certificate can be verified using a trusted root certificate pre-installed on the network management controller, and the first device endpoint certificate can be verified using the first intermediate certificate. This certificate chain verification method ensures that the certificate chain can be traced completely and effectively back to the trusted root certificate. Then, if the first device certificate chain verification is successful, both parties can establish a first secure channel.

[0077] For example, the first secure channel can be established based on the Transport Layer Security (TLS) protocol; therefore, the first secure channel can also be called a TLS secure channel. During the TLS handshake process, both parties can, for example, negotiate a temporary, shared session key specific to the current connection based on publicly available parameters using algorithms such as Diffie-Hellman key exchange. This key is used to encrypt subsequent communication data to achieve the function of a secure channel. Those skilled in the art should understand that the protocols used in this disclosure for establishing secure channels are not limited to the TLS protocol, but may also include other protocols capable of establishing secure channels.

[0078] In step S520, if the device unique identifier written in the first device terminal certificate of the electronic device matches the hardware identity of the electronic device, the electronic device can perform a cryptographic authentication key exchange with the network management controller via the first secure channel to generate a shared session key. For example, the media access control (MAC) address of the electronic device can be written as the device unique identifier in the first device terminal certificate. For example, the device unique identifier can be embedded in the certificate extension field of the first device terminal certificate. The device unique identifier written in the first device terminal certificate can be read by the network management controller and compared with the current device's identity information (e.g., hardware identity) to determine whether the device unique identifier and the current device's identity information match. After the network management controller determines that the device unique identifier matches the hardware identity of the electronic device, the electronic device can perform a cryptographic authentication key exchange with the network management controller via the first secure channel to generate a shared session key. The cryptographic authentication key exchange can be based on a cryptographic authentication key exchange protocol (PAKE), which includes, for example, SPAKE2, SPAKE2+, Secure Remote Cryptography Protocol (SRP), and Encryption Key Exchange (EKE).

[0079] In the process of cryptographic authentication key exchange, the network management controller can act as the prover, and the electronic device can act as the verifier. Performing the cryptographic authentication key exchange at the electronic device may include: generating a second temporary public key (as described above, temporary public key K1) based on a second derived value (as described above, derived value w) and a second random number (as described above, random number x); exchanging the second temporary public key (as described above, temporary public key K1) and a first temporary public key (as described above, temporary public key K2) generated by the network management controller via a first secure channel; and performing consistency verification based on the first temporary public key (as described above, temporary public key K2) and the second temporary public key (as described above, temporary public key K1) to complete the cryptographic authentication key exchange. The first temporary public key (as described above, temporary public key K2) may be generated based on a first derived value (as described above, derived value w') and a first random number (as described above, random number y). The second derived value (as described above, derived value w) may be a value generated by irreversibly calculating the user password registered during password registration, and the first derived value is a value generated by irreversibly calculating the input user password. For example, irreversible computations can include elliptic curve dot product calculations. Furthermore, the first and second random numbers can be generated each time a secure channel is established.

[0080] During the offline registration phase, a user can register a user password (e.g., "123456") on the network management controller. The network management controller can calculate a second derived value (derived value w as described above) from the registered user password. The electronic device can receive the second derived value (derived value w as described above) from the network management controller via an established secure channel. The second derived value (derived value w as described above) can be stored in the electronic device for subsequent consistency verification.

[0081] For example, the consistency verification process may include steps S10-S14 as described above. These steps are merely a specific example and are not limited to them. The consistency verification process can also employ other cryptographically strong verification methods, as long as the consistency of the passwords of both parties can be confirmed based on the public key. Electronic devices can use the Message Authentication Code (MAC) algorithm to calculate the second authentication code (authentication code C1 as described above) based on the received first temporary public key (temporary public key K2 as described above) and generate a session key K. shared For example, an electronic device can use a key derivation function to generate a confirmation key K based on the received first temporary public key (the temporary public key K2 as described above). confirmV and session key K shared And use the MAC algorithm based on the confirmation key K confirmVCalculate the second authentication code (authentication code C1 as described above) using the received first temporary public key (temporary public key K2 as described above). For example, C1 = MAC(K2). confirmV (, K2).

[0082] The electronic device can then send the second authentication code (authentication code C1 as described above) to the network management controller for consistency verification. The network management controller can then generate a confirmation key K based on the first temporary public key (temporary public key K2 as described above) in the same manner. confirmV The system calculates a fourth authentication code (authentication code C1' as described above), and then determines whether the calculated fourth authentication code (authentication code C1' as described above) matches the received second authentication code (authentication code C1 as described above). In response to the determination that the calculated fourth authentication code (authentication code C1' as described above) matches the received second authentication code (authentication code C1 as described above), the consistency verification of the second authentication code (authentication code C1 as described above) is successful; otherwise, it fails.

[0083] The electronic device can receive a first authentication code (authentication code C2 as described above) from the network management controller. The electronic device can then verify the consistency of the first authentication code (authentication code C2 as described above) received from the network management controller. The first authentication code (authentication code C2 as described above) is calculated by the network management controller using a Message Authentication Code (MAC) algorithm based on a second temporary public key (temporary public key K1 as described above). For example, the network management controller can use a key derivation function to generate a confirmation key K based on the received second temporary public key (temporary public key K1 as described above). confirmP and session key K shared and uses the MAC algorithm based on the confirmation key K confirmP Calculate the first authentication code (authentication code C2 as described above) using the received second temporary public key (temporary public key K1 as described above). For example, C2 = MAC(K1). confirmP For example, electronic device 210 can generate confirmation key K based on the second temporary public key (the temporary public key K1 as described above) in the same way. confirmP The system calculates a third authentication code (authentication code C2' as described above), and then determines whether the calculated third authentication code (authentication code C2' as described above) matches the received first authentication code (authentication code C2 as described above). In response to the determination that the calculated third authentication code (authentication code C2' as described above) matches the received first authentication code (authentication code C2 as described above), the consistency verification of the first authentication code (authentication code C2 as described above) is successful; otherwise, it fails.

[0084] For example, the first authentication code (authentication code C2 as described above) can be sent to the electronic device for consistency verification before the second authentication code (authentication code C1 as described above) is sent to the network management controller. In response to the failure of consistency verification of the first authentication code (authentication code C2 as described above), the failure counter at the electronic device is incremented, and in response to the value of the failure counter exceeding a predetermined threshold, the electronic device can determine to lock (i.e., prohibit) the verification operation for a predetermined period of time (e.g., 10 minutes, 30 minutes, or longer).

[0085] Once the consistency verification of the first and second authentication codes is successful, the key confirmation process (i.e., password authentication key exchange) can be completed, and the generated session key K can be... shared It has been determined to be a shared session key.

[0086] In step S530, the electronic device can perform encrypted transmission of communication messages with the network management controller based on the shared session key.

[0087] In one embodiment, such as Figure 2 As shown in step S15, the electronic device can use the shared session key K shared Alternatively, an application-layer encryption key derived from a shared session key (e.g., via a key derivation function) can be used to encrypt the communication messages. The electronic device can then transmit the encrypted communication messages to the network management controller via the first secure channel.

[0088] In another embodiment, such as Figure 3As shown in steps S16-S23, the electronic device can receive a second device certificate chain encrypted using a shared session key or a temporary encryption key derived from the shared session key (e.g., via a key derivation function). The second device certificate chain can be created for the electronic device by the network management controller. The second device certificate chain may include a root certificate, a second device terminal certificate, and a device private key. The electronic device can sign the second device terminal certificate using the device private key and send the second device certificate chain to the network management controller for verification. For example, the network management controller can first verify the validity of the second device terminal certificate using a pre-set CA root certificate and then verify the signature on the second device terminal certificate using the public key in the pre-set CA root certificate. Based on the verification result (i.e., verification passed), the electronic device can establish a second secure channel with the network management controller. The first secure channel can be disconnected before or simultaneously with the establishment of the second secure channel. For example, a new handshake (e.g., a TLS handshake) for establishing the second secure channel can be triggered when the first secure channel is disconnected. The new handshake can be a fast TLS handshake. After establishing the second secure channel, the electronic device can transmit communication messages with the network management controller via the second secure channel. During the handshake process of establishing a second secure channel, both parties can negotiate a temporary, shared session key K' specific to the current connection based on public parameters, for example, through algorithms such as Diffie-Hellman key exchange. shared This is used to encrypt subsequent communication data. The network management controller can then use the new shared session key K'. shared Or by a new shared session key K' shared (For example, through a key derivation function) a temporary encryption key is used to encrypt communication messages transmitted over a second secure channel.

[0089] A network management controller can create a second device certificate chain for an electronic device. This second device certificate chain may include a root certificate, a second device endpoint certificate, and a device private key. The network management controller can apply layer encryption to the second device certificate chain using a shared session key or a temporary encryption key derived from the shared session key (e.g., via a key derivation function). The network management controller can send the encrypted second device certificate chain to the electronic device via a first secure channel. The network management controller can verify the received second device endpoint certificate signed by the electronic device. For example, the network management controller can first verify the validity of the second device endpoint certificate using a pre-configured CA root certificate, and then verify the signature on the second device endpoint certificate using the public key in the pre-configured CA root certificate. Based on the verification result (i.e., successful verification), the network management controller can establish a second secure channel with the electronic device. The first secure channel can be disconnected before the second secure channel is established. For example, a new handshake (e.g., a TLS handshake) can be triggered when the first secure channel is disconnected to establish the second secure channel. The new handshake can be a fast TLS handshake. After establishing the second secure channel, the network management controller can transmit communication messages with the electronic device via the second secure channel. During the handshake process of establishing a second secure channel, both parties can negotiate a temporary, shared session key K' specific to the current connection based on public parameters, for example, through algorithms such as Diffie-Hellman key exchange. shared This is used to encrypt subsequent communication data. The network management controller can then use the new shared session key K'. shared Or by a new shared session key K' shared (For example, through a key derivation function) a temporary encryption key is used to encrypt communication messages transmitted over a second secure channel.

[0090] For the sake of brevity, please refer to the above for specific details. Figure 2 and Figure 3 The description will not be repeated here.

[0091] Figure 6 Example block diagrams of a network management controller 600 according to various embodiments of the present disclosure are shown.

[0092] like Figure 6 As shown, the network management controller 600 may include one or more processors 610 and memory 620. The processor 610 is communicatively coupled to the memory 620 and configured to perform the methods described above.

[0093] A set of computer program instructions stored in memory, when executed by at least one processor, performs any step of the above method, including: establishing a first secure channel with an electronic device, wherein, during the establishment of the first secure channel, a first device terminal certificate of the electronic device is obtained; determining whether a unique device identifier written in the first device terminal certificate matches the hardware identity of the electronic device; in response to the matching of the unique device identifier with the hardware identity of the electronic device, performing a cryptographic authentication key exchange with the electronic device via the first secure channel to generate a shared session key; and performing encrypted transmission of communication messages with the electronic device based on the shared session key. The above relates to... Figure 2 , 3 and Figure 4 The details described in the method shown also apply here.

[0094] Examples of processor 610 include microprocessors, microcontrollers, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform various functionalities throughout the present disclosure.

[0095] Processor 610 can execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other terms, software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc. Software can reside on memory 620.

[0096] Memory 620 may be a non-transitory computer-readable medium. As examples, non-transitory computer-readable media include magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes), optical disks (e.g., compact discs (CDs) or digital versatile discs (DVDs)), smart cards, flash memory devices (e.g., cards, sticks, or key drives), random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), registers, removable disks, and any other suitable medium for storing software and / or instructions that can be accessed and read by a computer. Memory 620 may reside in processor 610, be external to processor 610, or be distributed across multiple entities including processor 610. Memory 620 may be embodied in a computer program product. For example, a computer program product may include a computer-readable medium within encapsulation material. Those skilled in the art will recognize how the functionality described herein can be implemented depending on the specific application and the overall design constraints imposed on the system as a whole.

[0097] Additionally, according to another embodiment of this disclosure, a computer program product for an electronic device is disclosed. As an example, the computer program product includes a non-transitory computer-readable storage medium having program instructions embodied therein, and the program instructions are executable by a processor. When executed, the program instructions cause the processor to perform one or more of the processes described above, and details are omitted herein for brevity.

[0098] This disclosure can be a system, method, and / or computer program product at any possible level of technical detail integration. A computer program product may include a computer-readable storage medium (or medium) having computer-readable program instructions thereon for causing a processor to perform aspects of this disclosure.

[0099] Figure 7 Example block diagrams of an electronic device 700 according to various embodiments of the present disclosure are shown.

[0100] like Figure 7 As shown, the electronic device 700 may include one or more processors 710 and a memory 720. The processor 710 is communicatively coupled to the memory 720 and is configured to perform the methods described above.

[0101] A set of computer program instructions stored in memory, when executed by at least one processor, performs any step of the above-described method, including: establishing a first secure channel with a network management controller, wherein, during the establishment of the first secure channel, a first device terminal certificate of the electronic device is sent to the network management controller; if the device unique identifier written in the first device terminal certificate of the electronic device matches the hardware identity of the electronic device, performing a cryptographic authentication key exchange with the network management controller via the first secure channel to generate a shared session key; and performing encrypted transmission of communication messages with the network management controller based on the shared session key. The above relates to... Figure 2 , Figure 3 and Figure 5 The details described in the method shown also apply here.

[0102] Examples of processor 710 include microprocessors, microcontrollers, DSPs, FPGAs, PLDs, state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform various functionalities throughout the present disclosure.

[0103] Processor 710 can execute software. Whether referred to as software, firmware, middleware, microcode, hardware description language, or other terms, software should be broadly interpreted to mean instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executable files, execution threads, procedures, functions, etc. Software can reside on memory 720.

[0104] Memory 720 may be a non-transitory computer-readable medium, similar to memory 620, which will not be described further here.

[0105] Additionally, according to another embodiment of this disclosure, a computer program product for a server is disclosed. As an example, the computer program product includes a non-transitory computer-readable storage medium having program instructions embodied therein, and the program instructions are executable by a processor. When executed, the program instructions cause the processor to perform one or more of the processes described above, and details are omitted herein for brevity.

[0106] The firmware update method, electronic device, server, and system according to embodiments of the present disclosure have been described above with reference to the accompanying drawings. This disclosure does not rely on single-point authentication algorithms, but instead constructs a layered, multi-layered protection system encompassing secure channel establishment, device identity matching, two-way strong authentication and session key negotiation (i.e., cryptographic authentication key exchange, e.g., SPAKE2+), and application-layer encrypted transmission. This layered, multi-layered protection system effectively blocks attacks, thereby significantly improving overall communication security and preventing system-wide compromise due to the failure of a single security mechanism.

[0107] Unless otherwise expressly stated, expressions such as “according to,” “based on,” “depending on,” etc., as used in this disclosure do not mean “according to only,” “based on only,” or “depending on only.” In other words, in this disclosure, such expressions generally mean “at least according to,” “at least based on,” or “at least depending on.”

[0108] Any references to elements in this disclosure, such as the names "first," "second," etc., are not intended to comprehensively limit the number or order of these elements. These expressions may be used in this disclosure as a convenient way to distinguish two or more units. Therefore, references to the first unit and the second unit do not imply that only two units may be used, or that the first unit must precede the second unit in some form.

[0109] As used in this disclosure, the term "determine" can include a variety of operations. For example, "determine," calculation, operation, processing, derivation, investigation, search (e.g., searching in a table, database, or other data structure), and ascertainment are all considered "determine." Additionally, "determine" also refers to receiving (e.g., receiving information), sending (e.g., sending information), inputting, outputting, and accessing (e.g., accessing data in memory). Furthermore, "determine" can also refer to parsing, selecting, picking, building, and comparing. In other words, several actions can be considered "determine."

[0110] As used in this disclosure, terms such as “connection,” “coupling,” or any variation thereof refer to any direct or indirect connection or combination between two or more units, which may include situations where one or more intermediate units exist between two units that are “connected” or “coupled” to each other. The coupling or connection between units may be physical or logical, or a combination of both. As used in this disclosure, two units may be considered electrically connected by means of one or more wires, cables, and / or printing, and as numerous non-limiting and non-exhaustive examples, may be “connected” or “coupled” to each other by means of electromagnetic energy in the radio frequency region, microwave region, and / or light (visible and invisible) region, etc.

[0111] When the terms “comprising,” “including,” and variations thereof are used in this disclosure or claims, these terms are open-ended, just like the term “having.” Furthermore, the term “or” as used in this disclosure or claims is not an exclusive “or.”

[0112] Those skilled in the art will understand that many changes and / or modifications can be made to the present disclosure shown in the specific embodiments without departing from the spirit or scope of the present disclosure as broadly described. Therefore, the embodiments are to be considered illustrative rather than restrictive in all respects.

Claims

1. A secure communication method for a network management controller, comprising: A first secure channel is established with the electronic device, wherein a first device terminal certificate of the electronic device is obtained during the establishment of the first secure channel; Determine whether the unique device identifier written in the first device terminal certificate matches the hardware identity of the electronic device; In response to the unique identifier of the device matching the hardware identity of the electronic device, a cryptographic authentication key exchange is performed with the electronic device via the first secure channel to generate a shared session key; and Based on the shared session key, the electronic device performs encrypted transmission of communication messages.

2. The method according to claim 1, wherein, The encrypted transmission of communication messages with the electronic device based on the shared session key includes: The communication messages are encrypted at the application layer using the shared session key or a temporary encryption key derived from the shared session key; and Encrypted communication messages are transmitted to the electronic device via the first secure channel.

3. The method according to claim 1, wherein, The encrypted transmission of communication messages with the electronic device based on the shared session key includes: A second device certificate chain is created for the electronic device, the second device certificate chain including a root certificate, a second device terminal certificate and a device private key; The second device certificate chain is encrypted at the application layer using the shared session key or a temporary encryption key derived from the shared session key; The encrypted second device certificate chain is sent to the electronic device via the first secure channel; Verify the received second device terminal certificate signed by the electronic device; Based on the verification results, a second secure channel is established with the electronic device, and the first secure channel is disconnected; and The communication message is transmitted to the electronic device via the second secure channel.

4. The method according to claim 1, wherein, The network management controller acts as the certifier, the electronic device acts as the verifier, and the exchange of cryptographic authentication keys with the electronic device includes: A first temporary public key is generated based on a first derived value and a first random number. The first derived value is a value generated by irreversibly calculating the user password entered on the network management controller. The system exchanges a first temporary public key and a second temporary public key generated by the electronic device via the first secure channel. The second temporary public key is generated based on a second derived value and a second random number, and the second derived value is a value generated by irreversibly calculating the user's password registered during password registration. Consistency verification is performed based on the first temporary public key and the second temporary public key to complete the cryptographic authentication key exchange.

5. The method according to claim 4, wherein, The step of performing consistency verification based on the first temporary public key and the second temporary public key to complete the cryptographic authentication key exchange includes: The first authentication code is calculated based on the second temporary public key using the message authentication code algorithm. The first authentication code is sent to the electronic device for consistency verification by the electronic device; The consistency of the second authentication code received from the electronic device is verified, the second authentication code being calculated based on the first temporary public key using the message authentication code algorithm; and Based on the successful consistency verification of the first authentication code and the second authentication code, the exchange of the cryptographic authentication key is completed.

6. The method according to claim 5, wherein, The first authentication code is sent to the electronic device for consistency verification before the second authentication code is sent to the network management controller.

7. The method according to claim 4, wherein, The second derived value is sent from the network management controller to the electronic device and stored in the electronic device during the password registration.

8. The method according to claim 4, wherein, The first random number and the second random number are generated each time a secure channel is established.

9. The method according to claim 4, wherein, The irreversible calculations include elliptic curve dot product calculations.

10. The method according to claim 1, wherein, Establishing a first secure channel with the electronic device includes: Receive a first device certificate chain from the electronic device, the first device certificate chain including the first device terminal certificate and a first intermediate certificate. Verify the first device certificate chain, wherein the first intermediate certificate is verified using a trusted root certificate pre-installed on the network management controller, and the first device terminal certificate is verified using the first intermediate certificate; and If the verification of the first device certificate chain is successful, the first secure channel is established.

11. The method according to claim 1, wherein, The media access control MAC address of the electronic device is written into the first device terminal certificate as the unique identifier of the device.

12. The method according to claim 1, wherein, The cryptographic authentication key exchange includes SPAKE2+, an enhanced version of the simple cryptographic authentication key exchange.

13. A secure communication method for electronic devices, comprising: A first secure channel is established with the network management controller, wherein, during the establishment of the first secure channel, a first device terminal certificate of the electronic device is sent to the network management controller; If the unique device identifier written in the first device terminal certificate of the electronic device matches the hardware identity of the electronic device, a cryptographic authentication key exchange is performed with the network management controller via the first secure channel to generate a shared session key; and Encrypted transmission of communication messages is performed using the shared session key and the network management controller.

14. The method according to claim 13, wherein, Encrypting communication messages based on the shared session key and the network management controller includes: The communication messages are encrypted at the application layer using the shared session key or a temporary encryption key derived from the shared session key; and Encrypted communication messages are transmitted to the network management controller via the first secure channel.

15. The method according to claim 13, wherein, Encrypting communication messages based on the shared session key and the network management controller includes: Receive a second device certificate chain encrypted using the shared session key or a temporary encryption key derived from the shared session key, the second device certificate chain being created by the network management controller for the electronic device and including a root certificate, a second device terminal certificate, and a device private key; The second device terminal certificate is signed using the device private key, so that the network management controller can verify the second device terminal certificate; Based on the verification results, a second secure channel is established with the network management controller, and the first secure channel is disconnected; and The communication message is transmitted to the network management controller via the second secure channel.

16. The method according to claim 13, wherein, The network management controller acts as the certifier, and the electronic device acts as the verifier, and the exchange of cryptographic authentication keys with the network management controller includes: A second temporary public key is generated based on a second derived value and a second random number. The second derived value is a value generated by irreversibly calculating the user's password registered during the password registration period. The system exchanges a second temporary public key and a first temporary public key generated by the network management controller via the first secure channel. The first temporary public key is generated based on a first derived value and a first random number, and the first derived value is a value generated by irreversibly calculating the input user password. Consistency verification is performed based on the first temporary public key and the second temporary public key to complete the cryptographic authentication key exchange.

17. The method according to claim 16, wherein, The cryptographic authentication key exchange is completed by performing consistency verification based on the first temporary public key and the second temporary public key, including: The second authentication code is calculated based on the first temporary public key using the message authentication code algorithm. The second authentication code is sent to the network management controller for consistency verification by the network management controller; The consistency of the first authentication code received from the network management controller is verified, the first authentication code being calculated based on the second temporary public key using the message authentication code algorithm; and Based on the successful consistency verification of the first authentication code and the second authentication code, the exchange of the cryptographic authentication key is completed.

18. The method according to claim 17, wherein, The first authentication code is sent to the electronic device for consistency verification before the second authentication code is sent to the network management controller.

19. The method according to claim 18, wherein, The process of verifying consistency based on the first temporary public key and the second temporary public key to complete the cryptographic authentication key exchange also includes: In response to the failure of the consistency verification of the first authentication code, the value of the failure counter at the electronic device is incremented; and In response to the failure counter value exceeding a predetermined threshold, the password authentication key exchange is locked for a predetermined period of time.

20. A network management controller, comprising: One or more processors; Memory coupled to at least one of the processors in the processor; as well as A set of computer program instructions stored in the memory, which, when executed by at least one of the processors, perform the method as described in any one of claims 1-12.

21. An electronic device, comprising: One or more processors; Memory coupled to at least one of the processors in the processor; as well as A set of computer program instructions stored in the memory, which, when executed by at least one of the processors, perform the method as described in any one of claims 13-19.

22. A computer program product comprising computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1-19.

Images