Authentication processing method and device, computer equipment and readable storage medium

Abstract

The invention relates to an authentication processing method and device, computer equipment, a computer readable storage medium and a computer program product, which can be applied to the technical field of communication security. The method comprises the following steps: sending an initial connection request to a target bus based on initial authentication information of a device end, so that the target bus authenticates the initial authentication information to obtain an initial authentication result; receiving new authentication information of an equipment interface of the equipment end sent by the platform through the target bus under the condition of confirming that the equipment end is successfully connected with the target bus based on the initial authentication result; and sending a reconnection request to the target bus through the new authentication information of the device interface to enable the target bus to disable the initial authentication information, and authenticating the new authentication information to obtain a target authentication result. By adopting the method, the security of interface authentication can be improved.

Description

Technical Field

[0001] This application relates to the field of communication security technology, and in particular to an authentication processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of IoT technology, the communication needs between gateway platforms and various smart devices and plug-in modules are increasing daily. The M-bus (MBUS, Intelligent Management Bus), based on the MQTT (Message Queuing Telemetry Transport) protocol, serves as a unified communication middleware layer and is widely used for message passing and control between gateway platforms and downstream devices, plug-ins, vendor adaptation layers, and chip modules. With the widespread application of M-bus systems, the security authentication of device interfaces has become increasingly important. Therefore, how to securely authenticate interfaces has become a crucial research direction.

[0003] Traditional technologies typically use fixed usernames and passwords for interface authentication; however, this method requires storing fixed username and password information locally on the device for a long time. This fixed username and password information is usually stored in plaintext in the device's configuration file and remains unchanged over a long period, resulting in low security for interface authentication. Summary of the Invention

[0004] Therefore, it is necessary to provide an authentication processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the security of interface authentication in response to the above-mentioned technical problems.

[0005] Firstly, this application provides an authentication processing method. The method includes:

[0006] Based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains the initial authentication result;

[0007] If the device is confirmed to have successfully connected to the target bus based on the initial authentication result, the receiving platform sends new authentication information of the device interface of the device through the target bus.

[0008] Using the new authentication information from the device interface, a reconnection request is sent to the target bus, causing the target bus to disable the initial authentication information and authenticate the new authentication information to obtain the target authentication result.

[0009] In one embodiment, after receiving new authentication information of the device interface of the device side sent by the receiving platform via the target bus, the method further includes:

[0010] The new authentication information is encrypted based on the device identifier corresponding to the device to obtain encrypted authentication information;

[0011] The encrypted authentication information is stored in the local configuration file corresponding to the device interface.

[0012] In one embodiment, before sending a reconnection request to the target bus using new authentication information from the device interface, the method further includes:

[0013] The encryption authentication information is obtained from the local configuration file;

[0014] The encrypted authentication information is decrypted to obtain the new authentication information.

[0015] In one embodiment, sending a reconnection request to the target bus via new authentication information from the device interface includes:

[0016] The reconnection request is generated based on the new authentication information and the attribute information of the device interface;

[0017] Send the reconnection request to the target bus;

[0018] The platform is further configured to, when the target authentication result indicates that the authentication is successful, obtain the attribute information through the target bus, determine the permission configuration information of the device interface based on the attribute information, and perform permission configuration processing on the device interface based on the permission configuration information.

[0019] In one embodiment, the number of device interfaces is multiple;

[0020] The platform is also used to determine the permission configuration information of each device interface based on the attribute information of each device interface, and to perform permission configuration processing on each device interface based on the permission configuration information of each device interface.

[0021] In one embodiment, the method further includes:

[0022] The system receives an authentication information update instruction for the target device interface issued by the platform through a device node; the authentication information update instruction carries the updated authentication information and the summary information corresponding to the original authentication information.

[0023] The digest information corresponding to the original authentication information is verified to obtain the verification result of the authentication information update instruction;

[0024] If the verification result indicates that the verification is successful, the authentication information of the target device interface is updated according to the updated authentication information.

[0025] In one embodiment, after updating the authentication information of the target device interface based on the updated authentication information when the verification result indicates that the verification is successful, the method further includes:

[0026] Based on the updated authentication information, a reconnection request for the target device interface is generated;

[0027] The reconnection request is sent to the target bus; the target bus is used to reconnect the target device interface if the reconnection request is successfully authenticated.

[0028] Secondly, this application also provides an authentication processing apparatus for use on a device. The apparatus includes:

[0029] The first sending module is used to send an initial connection request to the target bus based on the initial authentication information of the device, so that the target bus authenticates the initial authentication information and obtains an initial authentication result;

[0030] The information receiving module is used to receive new authentication information of the device interface of the device sent by the platform through the target bus when the device is confirmed to have successfully connected to the target bus based on the initial authentication result.

[0031] The second sending module is used to send a reconnection request to the target bus through the new authentication information of the device interface, so that the target bus disables the initial authentication information and authenticates the new authentication information to obtain the target authentication result.

[0032] Thirdly, this application also provides a computer device. The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0033] Based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains the initial authentication result;

[0034] If the device is confirmed to have successfully connected to the target bus based on the initial authentication result, the receiving platform sends new authentication information of the device interface of the device through the target bus.

[0035] Using the new authentication information from the device interface, a reconnection request is sent to the target bus, causing the target bus to disable the initial authentication information and authenticate the new authentication information to obtain the target authentication result.

[0036] Fourthly, this application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program thereon, which, when executed by a processor, performs the following steps:

[0037] Based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains the initial authentication result;

[0038] If the device is confirmed to have successfully connected to the target bus based on the initial authentication result, the receiving platform sends new authentication information of the device interface of the device through the target bus.

[0039] Using the new authentication information from the device interface, a reconnection request is sent to the target bus, causing the target bus to disable the initial authentication information and authenticate the new authentication information to obtain the target authentication result.

[0040] Fifthly, this application also provides a computer program product. The computer program product includes a computer program that, when executed by a processor, performs the following steps:

[0041] Based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains the initial authentication result;

[0042] If the device is confirmed to have successfully connected to the target bus based on the initial authentication result, the receiving platform sends new authentication information of the device interface of the device through the target bus.

[0043] Using the new authentication information from the device interface, a reconnection request is sent to the target bus, causing the target bus to disable the initial authentication information and authenticate the new authentication information to obtain the target authentication result.

[0044] The aforementioned authentication processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product, based on the initial authentication information of the device, send an initial connection request to the target bus, causing the target bus to authenticate the initial authentication information and obtain an initial authentication result; if the device is confirmed to have successfully connected to the target bus based on the initial authentication result, a new authentication information of the device interface of the device is received by the platform through the target bus; and a reconnection request is sent to the target bus through the new authentication information of the device interface, causing the target bus to disable the initial authentication information and authenticate the new authentication information to obtain a target authentication result. This scheme establishes a temporary connection by sending an initial connection request to the target bus based on the initial authentication information from the device. This allows the device to quickly access the target bus and gain basic communication capabilities during the startup phase, thus creating the preconditions for subsequent dynamic updates of authentication information. After successfully connecting to the target bus, the device receives new authentication information from the platform's device interface, facilitating the dynamic distribution and updating of authentication credentials. This avoids the security risks associated with the device using fixed authentication information for extended periods, thereby improving authentication security. Finally, by using the new authentication information from the device interface to send a reconnection request and disabling the initial authentication information on the target bus, the scheme enables secure switching of authentication information. This ensures that the initial authentication information becomes invalid after completing its bootstrapping function, preventing malicious use and thus enhancing the security of interface authentication. Attached Figure Description

[0045] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0046] Figure 1 This is a flowchart illustrating the authentication process in one embodiment;

[0047] Figure 2 This is a flowchart illustrating the encryption process steps in one embodiment;

[0048] Figure 3 This is a flowchart illustrating the decryption process steps in one embodiment;

[0049] Figure 4 This is a flowchart illustrating the authentication processing method in another embodiment;

[0050] Figure 5 This is a flowchart illustrating the steps of remote dynamic account password change and mirror update in one embodiment;

[0051] Figure 6 This is a structural block diagram of the authentication processing device in one embodiment;

[0052] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0054] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0055] In one exemplary embodiment, such as Figure 1 As shown, an authentication processing method is provided. This embodiment illustrates the application of this method to a device (such as a terminal). It is understood that this method can also be applied to a terminal or a server, and can also be applied to a system including both a terminal and a server, implemented through interaction between the terminal and the server. The terminal can be, but is not limited to, various personal computers, laptops, smartphones, tablets, etc.; the server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. In this embodiment, the method includes the following steps:

[0056] Step S101: Based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains the initial authentication result.

[0057] Step S102: If the device is successfully connected to the target bus based on the initial authentication result, receive new authentication information of the device interface sent by the platform through the target bus.

[0058] Step S103: Send a reconnection request to the target bus using the new authentication information from the device interface, so that the target bus disables the initial authentication information and authenticates the new authentication information to obtain the target authentication result.

[0059] The target bus can be a unified communication middleware layer built on the MQTT (Message Queuing Telemetry Transport Protocol) protocol. For example, the target bus can be an M-bus (MBUS, Intelligent Management Bus) to realize communication between the platform and devices, chip modules, plug-ins, plug-ins and the manufacturer's underlying adaptation layer, and converged gateways and downstream devices.

[0060] Among them, the device end can be various access devices in the converged gateway platform. For example, the device end can be a plug-in with an M interface (such as M2, M3, M6, which is used to connect to the M bus), a manufacturer's adaptation layer, a chip module, a communication device such as a gateway or a smart terminal.

[0061] The initial authentication information can be the authentication credentials preset on the device for the first access, such as the preset initial authentication account and password.

[0062] The initial connection request can be the first connection request initiated based on the initial authentication information. For example, the initial connection request can be a connection request that completes the first authentication using a preset initial authentication account and password when the plugin first attempts to connect to the M bus.

[0063] The initial authentication result can be the authentication status result generated after the target bus verifies the initial authentication information. For example, the initial authentication result can be the result of whether the initial authentication account password verification is successful or unsuccessful.

[0064] The platform can be the control and management layer of the converged gateway system. For example, the platform can be an ITMS (IT Management System) or other management and control platform with device management and account / password distribution functions.

[0065] Among them, the device interface can be a specific functional interface for communication between the device and the target bus. For example, the device interface can be a communication interface with different permissions and functions, such as the M2 interface (computing power control), the M3 interface (system configuration), and the M6 ​​interface (image management).

[0066] Among them, the new authentication information for the device interface can be a unique authentication credential assigned by the platform to a specific device interface.

[0067] Among them, a reconnection request can be a second connection application initiated using new authentication information from the device interface. For example, a reconnection request can be a connection request from interfaces such as M2, M3, and M6, each using independent usernames and passwords, to connect to the M bus.

[0068] The target authentication result can be the authentication status result generated after the target bus verifies the new authentication information of the device interface. For example, the target authentication result can be the result of authentication success or failure after connecting to the M bus using the new authentication information of the device interface.

[0069] Optionally, after obtaining the initial authentication information from the device, the device establishes an initial connection with the target bus via the MQTT protocol. The device constructs an initial connection request message conforming to the MQTT protocol format based on a preset initial authentication cipher and sends the initial connection request to the target bus. Upon receiving the initial connection request, the target bus verifies the initial authentication information. If the verification is successful, it returns an initial authentication result indicating successful authentication. After confirming a successful connection to the target bus, the device begins listening for new authentication information from the platform's southbound read-only Topic channel for its device interface. The platform then sends the new authentication information to the device via the target bus. The terminal issues unique authentication credentials to each device interface. After receiving the new authentication information from the device interface, the device uses the unique device identifier to encrypt and store the new authentication information using a symmetric encryption algorithm. Then, each device interface, such as M2, M3, and M6, uses the new authentication information of the corresponding device interface to construct a reconnection request and send it to the target bus. After receiving the reconnection request, the target bus automatically cancels or disables the initial authentication information to prevent the initial authentication information from being reused continuously. At the same time, it performs authentication processing on the new authentication information of the device interface. After successful authentication, it returns the target authentication result (e.g., authentication successful).

[0070] In the above authentication process, based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains an initial authentication result; if the device side is confirmed to have successfully connected to the target bus based on the initial authentication result, new authentication information from the device interface on the device side is received by the platform through the target bus; through the new authentication information from the device interface, a reconnection request is sent to the target bus, so that the target bus disables the initial authentication information and authenticates the new authentication information to obtain the target authentication result. This scheme establishes a temporary connection by sending an initial connection request to the target bus based on the initial authentication information from the device. This allows the device to quickly access the target bus and gain basic communication capabilities during the startup phase, thus creating the preconditions for subsequent dynamic updates of authentication information. After successfully connecting to the target bus, the device receives new authentication information from the platform's device interface, facilitating the dynamic distribution and updating of authentication credentials. This avoids the security risks associated with the device using fixed authentication information for extended periods, thereby improving authentication security. Finally, by using the new authentication information from the device interface to send a reconnection request and disabling the initial authentication information on the target bus, the scheme enables secure switching of authentication information. This ensures that the initial authentication information becomes invalid after completing its bootstrapping function, preventing malicious use and thus enhancing the security of interface authentication.

[0071] In one exemplary embodiment, reference is made to Figure 2After receiving new authentication information from the device interface sent by the receiving platform via the target bus, it also includes:

[0072] Step S201: Based on the device identifier corresponding to the device, encrypt the new authentication information to obtain encrypted authentication information;

[0073] Step S202: Store the encrypted authentication information in the local configuration file corresponding to the device interface.

[0074] The device identifier can be a specific identifier used to uniquely identify the device, such as the device MAC (Media Access Control) address or device ID (identifier) ​​and other unique device identifiers.

[0075] The encryption process can be a process of encrypting and protecting new authentication information on the device interface. For example, the encryption process can be encrypting using a symmetric encryption algorithm with the device's unique identifier.

[0076] The encrypted authentication information can be new authentication information for the device interface after encryption.

[0077] The local configuration file can be a configuration data file stored locally on the device. For example, the local configuration file can be a configuration file on the plugin side of the device used to store the encryption and authentication information of each device interface.

[0078] Optionally, after receiving new authentication information from the device interface, the device obtains the corresponding device identifier, which includes a unique device identifier such as the device MAC address or device ID. Based on the device identifier as an encryption key, the device uses a security algorithm such as symmetric encryption to encrypt the new authentication information from the device interface. During the encryption process, the device encrypts the unique authentication credentials received from each device interface separately, including independently encrypting the credentials for interfaces M2, M3, and M6, to obtain the corresponding encrypted authentication information. After completing the encryption process, the device stores the encrypted authentication information in the local configuration file corresponding to each device interface. The local configuration file is located on the plugin side of the device to avoid storing the authentication information in plaintext in the core module of the device.

[0079] The technical solution provided in this embodiment encrypts the new authentication information of the device interface according to the device identifier corresponding to the device, which helps to avoid the authentication information existing in plaintext on the device and prevents the security risk of authentication credential leakage, thereby improving the security of authentication information.

[0080] In one exemplary embodiment, reference is made to Figure 3Before sending a reconnection request to the target bus using new authentication information from the device interface, the process also includes:

[0081] Step S301: Obtain encryption authentication information from the local configuration file;

[0082] Step S302: Decrypt the encrypted authentication information to obtain new authentication information.

[0083] Optionally, before the device needs to send a reconnection request with new authentication information through the device interface, the device reads the encrypted authentication information from the corresponding local configuration file for the specific device interface to be connected. The local configuration file includes files corresponding to the M2 interface, the M3 interface, the M6 ​​interface, etc. After obtaining the encrypted authentication information, the device uses the device identifier corresponding to the device as the decryption key. The device identifier is a unique device identifier such as the device MAC address or device ID. Based on the device identifier, the device uses the same symmetric encryption algorithm as during encryption to decrypt the encrypted authentication information. During the decryption process, the device independently decrypts the encrypted authentication information of each device interface to obtain the new authentication information of the corresponding device interface, including authentication credentials such as the M2 interface username and password, the M3 interface username and password, and the M6 ​​interface username and password.

[0084] The technical solution provided in this embodiment improves the security of authentication information by obtaining encrypted authentication information from a local configuration file. By decrypting the encrypted authentication information to obtain new authentication information for the device interface, it is possible to dynamically restore credentials when authentication information is needed, thereby enabling on-demand decryption and secure use of authentication information and reducing the security risks of authentication credentials.

[0085] In an exemplary embodiment, sending a reconnection request to the target bus using new authentication information from the device interface includes: generating a reconnection request based on the new authentication information and the attribute information of the device interface; sending the reconnection request to the target bus; wherein, the platform is further configured to, if the target authentication result indicates that the authentication is successful, obtain attribute information through the target bus, determine the permission configuration information of the device interface based on the attribute information, and perform permission configuration processing on the device interface based on the permission configuration information.

[0086] Among them, attribute information can be related information used to describe the characteristics and configuration of the device interface. For example, attribute information can be interface type (such as M2, M3, M6), device identifier, connection source address, device MAC address and other identification information.

[0087] The permission configuration information can be configuration data used to determine the access permissions and security policies of the device interface. For example, the permission configuration information can be access control rules such as different permission levels, network segment access restrictions, MAC whitelists, and token role labels configured based on interface type.

[0088] The permission configuration process can be the operation of setting access permissions and security control for device interfaces based on permission configuration information. For example, the permission configuration process can be the M bus performing multi-condition judgment based on parameters such as interface identifier, connection source IP, and identity token, combined with predefined ACL (Access Control List), to achieve fine-grained permission isolation and hierarchical access control.

[0089] Optionally, after obtaining new authentication information for the device interface, the device collects the interface's attribute information, including interface type identifier (e.g., M2, M3, M6), device identifier, connection source address, and device MAC address. Based on the new authentication information and attribute information of the device interface, the device constructs a reconnection request containing authentication credentials and interface characteristics. The reconnection request includes parameters such as authentication information, interface type identifier, device unique identifier, and connection source IP address. The device sends the reconnection request to the target bus via the MQTT protocol. The target bus receives the reconnection request. After each connection request, the platform verifies the new authentication information of the device interface. If the verification is successful, a target authentication result is generated. If the target authentication result indicates success, the platform obtains the attribute information of the device interface through the target bus. Based on the attribute information of the device interface, the platform determines the corresponding permission configuration information of the device interface. The permission configuration information of the device interface includes access control rules such as different permission levels configured based on interface type, network segment access restrictions, MAC whitelist, and Token role tags. Based on the permission configuration information of the device interface, the platform performs permission configuration processing on the device interface to achieve fine-grained permission isolation and hierarchical access control.

[0090] The technical solution provided in this embodiment determines the permission configuration information of the device interface based on attribute information and performs permission configuration processing. This facilitates differentiated permission management and fine-grained access control based on interface characteristics, ensuring that different types of device interfaces obtain corresponding access permissions. This, in turn, helps to achieve precise permission control and security protection based on hierarchical division of authority.

[0091] In one exemplary embodiment, there are multiple device interfaces; the platform is also used to determine the permission configuration information of each device interface based on the attribute information of each device interface, and to perform permission configuration processing on each device interface based on the permission configuration information of each device interface.

[0092] Among them, each device interface can refer to a collection of multiple different types of device interfaces. For example, each device interface can be a combination of multiple interfaces with different functions and permission levels, such as M2 interface, M3 interface, M6 interface, etc.

[0093] Among them, the attribute information of each device interface can refer to the characteristics and configuration information corresponding to each device interface. For example, the attribute information of each device interface can be the computing power control related attributes corresponding to the M2 interface, the system configuration related attributes corresponding to the M3 interface, the image management related attributes corresponding to the M6 ​​interface, and other exclusive identification information for different interface types.

[0094] The permission configuration information for each device interface can refer to the access permissions and security policy configuration data set for each device interface.

[0095] Optionally, after receiving the authentication results of multiple device interfaces, the platform obtains the attribute information of each device interface through the target bus. The platform analyzes and identifies the attribute information of each device interface, such as the M2 interface, M3 interface, and M6 interface, including identifying parameters such as interface type identifier, device identifier, and connection source address. Based on the attribute information of each device interface, the platform determines the corresponding permission configuration information of each device interface. Based on the permission configuration information of each device interface, the platform performs independent permission configuration processing for each device interface.

[0096] The technical solution provided in this embodiment enables fine-grained permission control and hierarchical management of multiple interfaces by independently configuring permissions for each device interface based on the permission configuration information of each device interface.

[0097] In an exemplary embodiment, the method further includes: receiving an authentication information update instruction for a target device interface issued by the platform through a device node; the authentication information update instruction carries updated authentication information and digest information corresponding to the original authentication information; performing verification processing on the digest information corresponding to the original authentication information to obtain a verification result of the authentication information update instruction; and updating the authentication information of the target device interface according to the updated authentication information if the verification result indicates that the verification is successful.

[0098] Among them, a device node can refer to a management interface node on the device side used to receive management instructions from the platform. For example, a device node can be a management node implemented based on the TR-069 protocol (Wide Area Network Management Protocol) used to receive various management instructions remotely issued by the platform.

[0099] The target device interface can refer to a specific device interface that needs to be updated with authentication information. For example, the target device interface can be a specific interface among interfaces with different functional permissions, such as the M2 interface, M3 interface, and M6 interface.

[0100] Among them, the authentication information update command can refer to the management command issued by the platform to the device to update the device interface authentication information. For example, the authentication information update command can be an update command containing the new account password and the original account password summary issued by calling the device management node path through the TR-069 protocol.

[0101] The updated authentication information can refer to the new authentication credentials issued by the platform to replace the original authentication information.

[0102] The digest information corresponding to the original authentication information can refer to a digital digest or hash value calculated based on the original authentication information.

[0103] Verification processing can refer to the operation of verifying and comparing the original authentication information digest. For example, verification processing can be the operation of calculating the digest of the currently stored account password on the device side and comparing it with the digest issued by the platform.

[0104] The verification result of the authentication information update instruction can refer to the verification conclusion obtained from the verification processing operation. For example, the verification result of the authentication information update instruction can be a judgment result that the digest matches, indicating that the verification has passed, or that the digest does not match, indicating that the verification has failed.

[0105] The update process can refer to the operation of replacing and updating the device interface authentication information after successful verification.

[0106] Optionally, the device receives an authentication information update command for the target device interface from the platform via a device node (which can be named tr069 node). The authentication information update command is sent via the TR-069 protocol by calling the device management node path. The authentication information update command carries the updated authentication information and the digest information corresponding to the original authentication information. The device verifies the digest information corresponding to the original authentication information received, including calculating the digest value of the currently saved authentication information of the target device interface, comparing the calculated digest value with the digest information corresponding to the original authentication information sent by the platform, and obtaining the verification result of the authentication information update command. When the verification result of the authentication information update command indicates that the digests are consistent, the verification is successful. When the verification result of the authentication information update command indicates that the digests are inconsistent, the verification fails and the update operation is rejected. If the verification result indicates that the verification is successful, the device updates the authentication information of the target device interface according to the updated authentication information, including updating the encrypted authentication information file stored locally on the target device interface with the updated authentication information, and notifying the corresponding process to reconnect to the target bus with the updated authentication information through process restart or connection reset.

[0107] The technical solution provided in this embodiment helps prevent malicious or illegal authentication information update operations by carrying the summary information corresponding to the original authentication information in the authentication information update instruction and performing verification processing. This ensures that only legitimate platform management instructions can execute authentication information updates, thereby improving the security of the authentication information update process. By only performing authentication information update processing when the verification result indicates that the verification has passed, it helps to establish a secure and controllable dynamic update mechanism for authentication information, avoiding security risks caused by illegal updates, and thus facilitating the secure rotation of authentication information.

[0108] In an exemplary embodiment, after updating the authentication information of the target device interface based on the updated authentication information when the verification result indicates that the verification is successful, the method further includes: generating a reconnection request for the target device interface based on the updated authentication information; sending the reconnection request to the target bus; and the target bus is used to reconnect the target device interface if the reconnection request is successfully authenticated.

[0109] A reconnection request can refer to a connection request message generated using the updated authentication information after the authentication information has been updated.

[0110] The reconnection process can refer to the operation of establishing a new authentication connection after the target bus verifies the reconnection request. For example, the reconnection process can be the target bus verifying the validity of the new account and password and then establishing a secure connection channel for the target device interface based on the updated authentication information.

[0111] Optionally, if the verification result indicates that the verification is successful, the device updates the authentication information of the target device interface according to the updated authentication information. Then, the device generates a reconnection request for the target device interface based on the updated authentication information and sends the reconnection request to the target bus. After receiving the reconnection request, the target bus performs authentication and verification on the reconnection request, including verifying the validity of the updated authentication information, verifying the permission identity of the target device interface, and checking whether the connection source address conforms to the ACL (Access Control List) configuration rules, among other multi-dimensional security verifications. If the reconnection request is successfully authenticated, the target bus performs reconnection processing on the target device interface, including establishing a secure connection channel for the target device interface based on the updated authentication information.

[0112] The technical solution provided in this embodiment generates a reconnection request for the target device interface based on the updated authentication information and sends it to the target bus. This helps ensure that the device interface can re-establish a secure connection using the new authentication credentials after the authentication information is updated. By authenticating and verifying the reconnection request through the target bus and then performing the reconnection process, the updated connection security and access control effectiveness are guaranteed.

[0113] The following application example illustrates the authentication processing method provided in this application. This application example demonstrates the application of this method to the device side.

[0114] This application example covers IoT device access control, communication security, and protocol middleware. It is particularly suitable for unifying and standardizing the communication protocols and content between the platform and devices, chip modules, plug-ins, plug-ins and the manufacturer's underlying adaptation layer, and between the converged gateway and its downstream devices (slave gateways, smart terminals, etc.) using the MBUS protocol in a converged gateway architecture. It constructs a simple, open, unified, and scalable communication authentication and security enhancement mechanism.

[0115] The M-bus is a unified communication middleware layer built on the MQTT protocol, widely used for message passing and control between converged gateway platforms and downstream devices, plugins, vendor adaptation layers, and chip modules. In the current M-bus system's authentication mechanism, each M interface (such as M2, M3, and M6) uses a fixed username and password to connect to the M-bus, and these authentication usernames and passwords are typically stored in the device's local pwfile (password file). Because these usernames and passwords are fixed and unchanging, if obtained by a malicious attacker, they could directly connect to the M-bus and perform unauthorized device operations, posing a security threat.

[0116] Taking the M3 interface as an example, attackers can use it to modify administrator passwords, SSH (Secure Shell) passwords, or Wi-Fi configurations; leakage of account passwords on the M6 ​​interface may lead to destructive operations such as image stopping or deletion; and intrusion into the M2 interface may cause high-risk consequences such as the failure of edge computing modules. Therefore, the existing security mechanisms of the M bus have obvious deficiencies in terms of hierarchical control, key updates, and access domain isolation.

[0117] To address the shortcomings of existing technologies, this application example aims to provide a secure, flexible, and multi-domain-enabled M-bus authentication control method and system, resolving the key leakage risks and lack of secure isolation inherent in existing fixed-key / account mechanisms. Through dynamic key / account distribution, a one-time authentication mechanism, and encrypted storage strategies, the security and controllability of the M-interface communication process are improved.

[0118] To achieve the above objectives, this application example proposes the following two complementary solutions, which can be deployed independently or used in combination:

[0119] Option 1: Dynamic account password issuance and one-time authentication mechanism.

[0120] Authentication initialization phase:

[0121] The M-bus only stores the initial authentication password for the plugin, which is used for authentication when the plugin first connects to the M-bus.

[0122] Account password distribution channel:

[0123] A new read-only southbound Topic channel has been added to the M bus as a channel for distributing account and password information. When a device first connects to the platform from the north, the platform uses this Topic to distribute the corresponding M interface account and password (e.g., M2, M3, M6, etc.) to the plug-in.

[0124] Encrypted storage of account passwords:

[0125] After receiving the account password, the plugin stores it locally using symmetric encryption, such as AES (Advanced Encryption Standard) or SM4 (Encryption Algorithm), to prevent plaintext leakage.

[0126] Certification Upgrade:

[0127] After receiving and storing the M-interface account key, the plugin uses the new account key to connect to the M-bus, and at the same time cancels or disables the initial account key originally used for the first access, thus realizing a one-time authentication mechanism.

[0128] Subsequent communication:

[0129] Each M interface uses its corresponding username and password for authentication independently, and the platform can configure different permission levels and security policies according to the importance of the interface.

[0130] refer to Figure 4 The device-side plugin checks if an account and password exist. If they do, it decrypts the account and password to log in; otherwise, it uses the default account and password to log in. The M-bus sends a request to the platform through the account and password distribution channel. The platform sends a new account and password to the M-bus, which then sends the new account and password to the plugin. The plugin uses AES (Advanced Encryption Standard) to encrypt and save the account and password. When needed, it decrypts the account and password to log in. The M-bus disables the default account and password.

[0131] Option 2: Remote dynamic account password change and mirror update mechanism.

[0132] Account password change mechanism:

[0133] Without changing the existing authentication architecture, the device adds a TR-069 management node, through which the platform can remotely issue new usernames and passwords to the device.

[0134] Account password verification mechanism:

[0135] Before changing the account password, the device must use the currently saved account password for signature or digest verification. Only after the verification is passed can the password be modified to prevent the account password from being illegally tampered with.

[0136] Mirror update synchronization:

[0137] For M interfaces that require mirroring (such as M2 and M6), new account passwords can be synchronized through the mirror upgrade mechanism to maintain the security of the interface connection.

[0138] Access control domain isolation:

[0139] Different M interfaces belong to different permission domains. The M bus can control and isolate access permissions based on elements such as interface ID (identifier), authentication identity, and connection source address to prevent single point leakage from causing lateral control risks.

[0140] refer to Figure 5 , Figure 5 The process of remote dynamic account password change and image update is demonstrated, including: adding a new tr069 node, the platform issuing a new account password, determining whether the old account password needs to be verified, if not, using the new account password through image upgrade; if so, modifying the saved account password, using the new account password to connect to the M bus, and using the new account password through image upgrade.

[0141] Compared with existing M-bus systems that use fixed usernames and passwords, static authentication, and unisolated permissions, the M-bus access control method and system based on the MQTT protocol proposed in this application example has significant advantages in terms of security, flexibility, and manageability and controllability, as specifically demonstrated below:

[0142] Enhance authentication security and prevent the long-term exposure of fixed account passwords:

[0143] This application example avoids the security risks associated with storing fixed passwords locally for extended periods by using dynamic username and password distribution and a one-time authentication mechanism. The platform distributes usernames and passwords for each interface upon initial device connection and automatically cancels the initial authentication password after configuration is complete. Even if an attacker obtains the initial authentication information, they cannot maintain long-term control of the device.

[0144] Implement interface-level permission stratification and domain isolation:

[0145] This application example divides each M interface (such as M2, M3, M6) into independent permission domains and performs fine-grained control based on factors such as interface type, identity credentials, and source address to prevent the leakage of a single account password from causing the entire chain to go out of control, thereby enhancing the overall robustness and anti-attack capability of the system.

[0146] Supports remote dynamic updates and periodic rotation of account passwords:

[0147] This application example introduces the TR-069 remote management protocol to enable the secure remote distribution and update of M interface account keys. The platform can periodically rotate keys for high-privilege interfaces, greatly reducing potential leakage windows and meeting the compliance requirements of enterprise-level security management.

[0148] Ensuring the legitimacy and non-repudiation of account password updates:

[0149] Introducing an old key signature or digest verification mechanism during the password change process ensures that only legitimate platforms or authorized personnel can modify account passwords, preventing malicious or accidental operations from causing device communication interruptions or illegal tampering.

[0150] Compatible with existing system architecture, simple upgrade and deployment:

[0151] This application example solution is designed with full consideration of compatibility with the existing M-bus system. The distribution of account passwords, the introduction of authentication modules, and the access control mechanism can all be completed through plugin updates or firmware image upgrades without significant changes to the device architecture, making it easy to deploy quickly.

[0152] The implementation method of this application example is described in detail below.

[0153] Example 1: Initial Authentication and Dynamic Account Password Issuance Process:

[0154] In this embodiment, after a device is started for the first time, its plug-in attempts to connect to the M bus for the first time and completes the initial authentication using a preset initial authentication account and password.

[0155] After a successful connection, the platform will send the corresponding M interface usernames and passwords to the device via the MQTT southbound read-only Topic channel. For example: M2 interface username and password: m2XXX; M3 interface username and password: m3XXX; M6 interface username and password: m6XXX.

[0156] Once the plugin listens to the Topic and receives these account passwords, it immediately performs symmetric encryption using a unique device identifier (such as the device MAC address or device ID) and saves them in a local configuration file.

[0157] Afterwards, interfaces M2, M3, and M6 each connect to the M bus using independent account passwords, and the original initial account passwords are deactivated, rendering the initial account passwords invalid or deleted.

[0158] This process achieves a complete closed loop of plugin initialization, dynamic distribution of account and password, encrypted storage of account and password, and hierarchical connection, which significantly improves the security and controllability of device access.

[0159] Example 2: The platform remotely issues new account passwords and verifies and updates them:

[0160] Among the numerous gateway devices deployed by a certain organization, some have M3 interfaces that grant permissions to modify system administrator passwords and Wi-Fi configurations. To further enhance security, the platform administrator decided to implement password rotation for the M3 interfaces.

[0161] The platform calls the newly added management node of the device through the TR-069 protocol and issues a new account password string: New account password: m3XXXXX; Old account password digest: sha256 (secure hash algorithm 256).

[0162] After receiving the instruction, the device automatically calculates the digest of the currently stored account password and compares it with the digest issued by the platform: if the digests match, the update operation is successful; if the digests do not match, the update is rejected and a log is recorded to prevent malicious replacement.

[0163] After a successful update, the device will update the encrypted account and password file stored locally on the M3 interface, and at the same time notify the M3 process to reconnect to the M bus with the new account and password by restarting the process or resetting the connection.

[0164] This embodiment ensures the integrity and legitimacy of password rotation, preventing unauthorized commands from causing system security to spiral out of control.

[0165] Example 3: Interface Permission Domain Isolation and Access Control

[0166] Three plugins, M2 (computing power control), M3 (system configuration), and M6 (image management), run simultaneously on a certain device.

[0167] According to the security policy, the platform configures different permission levels and access ranges for each M interface:

[0168] The M2 interface only allows access from clients in the 192.168.XXX.0 / 24 network segment;

[0169] The M3 interface only allows access to devices on specific MAC whitelists;

[0170] The M6 ​​interface requires additional verification to determine whether the client has the image control permission tag (the Token contains the fields "role" and "image_admin").

[0171] When the M bus receives a connection request, it uses parameters such as the interface identifier (e.g., topic prefixed with / M3 / ), connection source IP (Internet Protocol), and identity token in the authentication information, combined with predefined ACLs, to perform multi-condition judgments and achieve fine-grained permission isolation.

[0172] When an attacker attempts to connect to the M bus from an unauthorized IP address using an M3 interface account and password, the connection will be rejected, and a security audit log will be triggered.

[0173] This embodiment further enhances interface isolation and hierarchical control capabilities, effectively preventing lateral access attacks.

[0174] This application example involves an M-bus authentication control mechanism based on the MQTT protocol. Addressing issues such as easy leakage of fixed account passwords, coarse access control, and static, unchanging authentication mechanisms in current converged gateway environments, the following key technical points and effects are proposed:

[0175] 1. M-bus initialization authentication and dynamic account / password distribution mechanism:

[0176] Only plugins are allowed to access the M-bus using a one-time initial account password;

[0177] The platform distributes unique account passwords to each M interface via a southbound read-only Topic;

[0178] After receiving the password, the plugin encrypts and stores it, and then switches to use the new password to connect to the M bus.

[0179] This mechanism establishes a dynamic and controllable authentication system, effectively preventing long-term control risks after the leakage of fixed passwords.

[0180] 2. Access control mechanism for M-interface with different permissions and domains:

[0181] Different M interfaces (such as M2, M3, and M6) define independent authentication identities and permission domains;

[0182] The M-bus performs access determination based on multiple dimensions such as interface type, identity credentials, and connection source.

[0183] It supports the configuration of complex rules such as ACL, Token role tags, and IP or MAC whitelists.

[0184] This mechanism enables fine-grained access control, preventing single-point breaches from leading to unauthorized lateral operations.

[0185] 3. Encrypted storage and decoupling mechanism for interface account passwords:

[0186] The account passwords for each interface are no longer stored uniformly in the M-bus core module, but are instead stored separately on the plug-in side;

[0187] The plug-in reconciliation password is encrypted using a symmetric encryption algorithm with device identifiers and then stored to prevent plaintext leakage.

[0188] The interface connection authentication logic is decoupled from the bus control, enhancing module autonomy and system resilience.

[0189] This mechanism enhances the local security of account passwords while improving the system's architectural flexibility and inter-module isolation.

[0190] 4. Mechanism supporting remote and secure account password changes:

[0191] A new TR-069 management node has been added to the device side, and the platform can remotely issue new account passwords to the interface;

[0192] Before updating the account password, the original account password summary or signature must be verified to prevent unauthorized tampering.

[0193] After a successful update, the new account and password connection can be activated by restarting via image or reconnecting via plugin.

[0194] This mechanism enables secure rotation of account passwords under centralized platform control, meeting the needs of operational compliance and dynamic adjustment of security strategies.

[0195] 5. One-time authentication and initial account disabling mechanism:

[0196] The initial authentication password is discarded upon first integration of the plugin to prevent it from being reused repeatedly.

[0197] The M-bus identifies and initializes the account identity, and forcibly cancels its permissions after the account and password are issued.

[0198] This mechanism cuts off the path for attackers to continuously control devices using initial authentication information.

[0199] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0200] Based on the same inventive concept, this application also provides an authentication processing apparatus for implementing the authentication processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more authentication processing apparatus embodiments provided below can be found in the limitations of the authentication processing method described above, and will not be repeated here.

[0201] In one exemplary embodiment, such as Figure 6 As shown, an authentication processing apparatus 600 is provided, which may include:

[0202] The first sending module 601 is used to send an initial connection request to the target bus based on the initial authentication information on the device side, so that the target bus can authenticate the initial authentication information and obtain the initial authentication result.

[0203] The information receiving module 602 is used to receive new authentication information of the device interface of the device sent by the platform through the target bus when the device is confirmed to be successfully connected to the target bus based on the initial authentication result.

[0204] The second sending module 603 is used to send a reconnection request to the target bus through the new authentication information of the device interface, so that the target bus disables the initial authentication information and authenticates the new authentication information to obtain the target authentication result.

[0205] In an exemplary embodiment, the device 600 further includes: an encryption processing module, configured to encrypt the new authentication information according to the device identifier corresponding to the device end, to obtain encrypted authentication information; and to store the encrypted authentication information in a local configuration file corresponding to the device interface.

[0206] In an exemplary embodiment, the device 600 further includes: a decryption processing module, configured to obtain encrypted authentication information from a local configuration file; and to decrypt the encrypted authentication information to obtain new authentication information.

[0207] In an exemplary embodiment, the second sending module 603 is further configured to generate a reconnection request based on the new authentication information and the attribute information of the device interface; and send the reconnection request to the target bus; wherein, the platform is further configured to obtain attribute information through the target bus when the target authentication result indicates that the authentication is successful, determine the permission configuration information of the device interface based on the attribute information, and perform permission configuration processing on the device interface based on the permission configuration information.

[0208] In one exemplary embodiment, there are multiple device interfaces; the platform is also used to determine the permission configuration information of each device interface based on the attribute information of each device interface, and to perform permission configuration processing on each device interface based on the permission configuration information of each device interface.

[0209] In an exemplary embodiment, the device 600 further includes: an instruction receiving module, configured to receive an authentication information update instruction for a target device interface issued by the platform through a device node; the authentication information update instruction carries updated authentication information and digest information corresponding to the original authentication information; the digest information corresponding to the original authentication information is verified to obtain a verification result of the authentication information update instruction; if the verification result indicates that the verification is successful, the authentication information of the target device interface is updated according to the updated authentication information.

[0210] In an exemplary embodiment, the device 600 further includes: a request generation module, configured to generate a reconnection request for the target device interface based on the updated authentication information; send the reconnection request to the target bus; and the target bus is configured to reconnect the target device interface if the reconnection request is successfully authenticated.

[0211] Each module in the aforementioned authentication processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0212] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements an authentication processing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0213] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0214] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0215] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above-described method embodiments.

[0216] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0217] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0218] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0219] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An authentication processing method, characterized in that, Applied to the device side, the method includes: Based on the initial authentication information on the device side, an initial connection request is sent to the target bus, so that the target bus authenticates the initial authentication information and obtains the initial authentication result; If the device is confirmed to have successfully connected to the target bus based on the initial authentication result, the receiving platform sends new authentication information of the device interface of the device through the target bus. Using the new authentication information from the device interface, a reconnection request is sent to the target bus, causing the target bus to disable the initial authentication information and authenticate the new authentication information to obtain the target authentication result.

2. The method according to claim 1, characterized in that, After receiving the new authentication information of the device interface on the receiving platform via the target bus, the process further includes: The new authentication information is encrypted based on the device identifier corresponding to the device to obtain encrypted authentication information; The encrypted authentication information is stored in the local configuration file corresponding to the device interface.

3. The method according to claim 2, characterized in that, Before sending a reconnection request to the target bus using the new authentication information from the device interface, the process also includes: The encryption authentication information is obtained from the local configuration file; The encrypted authentication information is decrypted to obtain the new authentication information.

4. The method according to claim 1, characterized in that, Sending a reconnection request to the target bus via the new authentication information from the device interface includes: The reconnection request is generated based on the new authentication information and the attribute information of the device interface; Send the reconnection request to the target bus; The platform is further configured to, when the target authentication result indicates that the authentication is successful, obtain the attribute information through the target bus, determine the permission configuration information of the device interface based on the attribute information, and perform permission configuration processing on the device interface based on the permission configuration information.

5. The method according to claim 4, characterized in that, The number of device interfaces is multiple; The platform is also used to determine the permission configuration information of each device interface based on the attribute information of each device interface, and to perform permission configuration processing on each device interface based on the permission configuration information of each device interface.

6. The method according to claim 1, characterized in that, The method further includes: The system receives an authentication information update instruction for the target device interface issued by the platform through a device node; the authentication information update instruction carries the updated authentication information and the summary information corresponding to the original authentication information. The digest information corresponding to the original authentication information is verified to obtain the verification result of the authentication information update instruction; If the verification result indicates that the verification is successful, the authentication information of the target device interface is updated according to the updated authentication information.

7. The method according to claim 6, characterized in that, If the verification result indicates that the verification is successful, after updating the authentication information of the target device interface based on the updated authentication information, the process further includes: Based on the updated authentication information, a reconnection request for the target device interface is generated; The reconnection request is sent to the target bus; the target bus is used to reconnect the target device interface if the reconnection request is successfully authenticated.

8. An authentication processing device, characterized in that, Applied to the device side, the device includes: The first sending module is used to send an initial connection request to the target bus based on the initial authentication information of the device, so that the target bus authenticates the initial authentication information and obtains an initial authentication result; The information receiving module is used to receive new authentication information of the device interface of the device sent by the platform through the target bus when the device is confirmed to have successfully connected to the target bus based on the initial authentication result. The second sending module is used to send a reconnection request to the target bus through the new authentication information of the device interface, so that the target bus disables the initial authentication information and authenticates the new authentication information to obtain the target authentication result.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images