A method and system for switching ADB login identity and permissions

Abstract

This application discloses a method and system for switching ADB login identity permissions, applied to an ECU. The method involves receiving a connection request message and obtaining the target permission indicated by the message; the target permission may be ordinary permission or administrator permission. If the target permission is administrator permission, a first message is sent to the host computer. A first signature information message is received, carrying first signature information. The host computer's identity is verified based on the first signature information, and a verification result is obtained. After the verification result indicates that the host computer's identity verification is successful, the legality of the host computer's signature information is verified. If the host computer's signature information is legal, a first connection request response message is sent to the host computer, allowing the host computer to switch its ADB login identity permission to administrator permission. Thus, login identity escalation can be achieved without restarting the vehicle system, enriching the means of real-vehicle fault analysis while ensuring the security of the vehicle system.

Description

Technical Field

[0001] This application relates to the field of device communication technology, and in particular to a method and system for switching ADB login identity permissions. Background Technology

[0002] Android Debug Bridge (ADB) is a versatile command-line tool that provides a universal interface that allows developers to perform operations such as debugging, installing applications, and transferring files on devices via a host computer. ADB mainly consists of three components: the ADB server, the ADB client, and the ADB daemon (also known as Adbd).

[0003] During the analysis of real-vehicle system problems, ADB was used for operations such as log export, device login, and problem analysis. In the ADB debugging scheme, the login identity of the device-side Adbd process is divided into two types: super administrator (root) and ordinary user (shell). The host computer logs into the device using ADB commands with the same identity as the running identity of the Adbd process. When logging into the device as root, one has super administrator privileges and can perform any operation; when logging into the device as shell, one can only perform operations with the corresponding permissions of the shell user.

[0004] However, in real-world vehicle systems, to ensure the security of system resources and vehicle operational data, ADB is configured to start with shell privileges by default. When logging in as shell, if problems arise in the vehicle system, it is necessary to switch to root privileges to access higher-level files and use higher-level permissions to investigate the cause of the problem.

[0005] Currently, traditional ADB login identity management methods require a system restart and configuration changes to switch the login identity to the root user. However, after a system restart, issues encountered when accessing the system as a shell user may disappear. This is because restarting the system not only alters the vehicle's operational status information but can also render the analyzed issues unreproducible, impacting the fault analysis results of the actual vehicle system. Therefore, there is an urgent need for a method to switch ADB login identity permissions quickly without restarting the system, thereby reducing security risks in the actual vehicle system. Summary of the Invention

[0006] This application provides a method and system for switching ADB login identity permissions, which can quickly switch login identity permissions without restarting the system, thereby reducing the security risks of the real vehicle system to a certain extent.

[0007] In a first aspect, this application provides a method for switching ADB login identity permissions, applied to an electronic control unit (ECU), wherein the ECU is communicatively connected to a host computer, and the method includes:

[0008] Receive a connection request message and obtain the target permission indicated by the connection request message; the connection request message is sent by the host computer to the ECU in response to a permission switching instruction; the permission switching instruction instructs the host computer to switch the permissions of the ADB login identity to the target permission; the target permission includes ordinary permissions or administrator permissions;

[0009] If the target permission is the administrator permission, send the first message to the host computer;

[0010] Receive a first signature information message, the first signature information message carrying first signature information; the first signature information is obtained by the host computer after signing the first message using the target private key;

[0011] The host computer is verified based on the first signature information to obtain the identity verification result.

[0012] After the identity verification result indicates that the host computer's identity verification has passed, the legality of the host computer's signature information is verified.

[0013] If the signature information of the host computer is valid, a first connection request response message is sent to the host computer. The first connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to the administrator permissions.

[0014] Optionally, the step of verifying the identity of the host computer based on the first signature information to obtain the identity verification result includes:

[0015] If a pre-stored public key that matches the first signature information exists, then the first identity verification result indicates that the identity verification of the host computer has passed; the pre-stored public key is stored after identity verification.

[0016] The identity verification result obtained is the first identity verification result.

[0017] Optionally, after the identity verification result indicates that the host computer's identity verification has passed, verifying the legality of the host computer's signature information includes:

[0018] After the identity verification result indicates that the host computer has passed the identity verification, the pre-stored public key information of the pre-stored public key is extracted;

[0019] The legitimacy of the first signature information is verified based on the pre-stored public key information.

[0020] Optionally, the step of verifying the identity of the host computer based on the first signature information to obtain the identity verification result includes:

[0021] If no pre-stored public key matching the first signature information exists, the first identity verification result indicates that the identity verification of the host computer has failed.

[0022] Send a second message to the host computer;

[0023] Save the target public key sent by the host computer, wherein the target public key corresponds to the target private key;

[0024] Send a third message to the host computer;

[0025] Receive a second signature information message; the second signature information message carries second signature information, which is obtained by the host computer after signing the third message using the target private key;

[0026] The host computer is used to verify the identity of the target public key to obtain a second identity verification result.

[0027] The identity verification result is obtained as the second identity verification result.

[0028] Optionally, the step of verifying the identity of the host computer based on the target public key to obtain a second identity verification result includes:

[0029] Extract the device identifier of the host computer from the target public key;

[0030] The second identity verification result is obtained by comparing the device identifier with the device information in the preset whitelist.

[0031] Optionally, after the identity verification result indicates that the host computer's identity verification has passed, verifying the legality of the host computer's signature information includes:

[0032] After the identity verification result indicates that the host computer has passed the identity verification, the target public key information of the target public key is extracted from the target public key;

[0033] Optionally, the method further includes:

[0034] If the signature information of the host computer is invalid, a second connection request response message is sent to the host computer. The second connection request response message indicates that the host computer is not allowed to switch the permissions of the ADB login identity to the administrator permissions.

[0035] Optionally, the method further includes:

[0036] If the target permission is the normal permission, a third connection request response message is sent to the host computer, the third connection request response message indicating that the host computer is allowed to switch the ADB login identity permission to the normal permission.

[0037] Secondly, this application also provides a method for switching ADB login identity permissions, applied to a host computer, wherein the host computer is communicatively connected to an electronic control unit (ECU), and the method includes:

[0038] In response to a permission switching command, a connection request message is sent to the ECU; the connection request message is used to indicate the target permission; the permission switching command indicates that the permissions of the ADB login identity be switched to the target permission; the target permission includes ordinary permissions or administrator permissions;

[0039] The system receives a first message and sends a first signature information message to the ECU, so that the ECU can verify the identity of the host computer and verify the legality of the host computer's signature information based on the first signature information; the first message is sent by the ECU to the host computer after obtaining the target's administrator privileges; the first signature information message carries first signature information; the first signature information is obtained by the host computer after signing the first message using the target's private key;

[0040] Upon receiving the first connection request response message, the permissions of the ADB login identity are switched to the administrator permissions; the first connection request response message is sent by the ECU after the identity verification of the host computer is passed and the signature information of the host computer is valid, and the first connection request response message indicates that the permissions of the ADB login identity are allowed to be switched to the administrator permissions.

[0041] Optionally, the method further includes:

[0042] A key pair is generated using the RSA encryption algorithm, the key pair including an initial private key and an initial public key; the initial public key is generated based on the initial private key.

[0043] Save the initial private key as the target private key;

[0044] The initial public key is packaged and encoded according to a preset format to obtain the encoded initial public key;

[0045] A target public key is generated based on the device identifier of the host computer and the encoded initial public key, and the target public key corresponds to the target private key; the device identifier includes the username of the ADB login identity and the computer name of the host computer.

[0046] Thirdly, this application also provides a system for switching ADB login identity permissions, characterized in that the system includes an electronic control unit (ECU) and a host computer;

[0047] The host computer is used to send a connection request message to the ECU in response to a permission switching command; the connection request message is used to indicate the target permission; the permission switching command indicates to switch the permissions of the ADB login identity to the target permission; the target permission includes ordinary permissions or administrator permissions;

[0048] The ECU is configured to receive the connection request message and obtain the target permission indicated by the connection request message;

[0049] The ECU is further configured to send a first message to the host computer if the target permission is the administrator permission;

[0050] The host computer is also used to receive the first message and send a first signature information message to the ECU; the first signature information message carries first signature information; the first signature information is obtained by the host computer after signing the first message using the target private key;

[0051] The ECU is also used to perform identity verification on the host computer based on the first signature information and obtain the identity verification result;

[0052] The ECU is also used to verify the legality of the signature information of the host computer after the identity verification result indicates that the identity verification of the host computer has passed;

[0053] The ECU is further configured to send a first connection request response message to the host computer if the signature information of the host computer is valid. The first connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to the administrator permissions.

[0054] The host computer is also configured to switch the permissions of the ADB login identity to the administrator permissions after receiving the first connection request response message.

[0055] Therefore, this application has the following beneficial effects:

[0056] This application provides a method and system for switching ADB login identity permissions. The method is applied to an ECU, which communicates with a host computer. The method includes receiving a connection request message and obtaining the target permission indicated by the connection request message. The connection request message is sent by the host computer to the ECU in response to a permission switching instruction. The permission switching instruction instructs the host computer to switch the ADB login identity permission to the target permission. The target permission includes ordinary permission or administrator permission. If the target permission is administrator permission, a first message is sent to the host computer. A first signature information message is received, carrying first signature information. The first signature information is obtained by the host computer signing the first message using the target private key. The host computer performs identity verification based on the first signature information to obtain an identity verification result. After the identity verification result indicates that the host computer's identity verification is successful, the legality of the host computer's signature information is verified. If the host computer's signature information is legal, a first connection request response message is sent to the host computer, indicating that the host computer is allowed to switch the ADB login identity permission to administrator permission. Thus, based on receiving the first signature information message, and with the host computer's identity verification passed and the host computer's signature information verified as valid, the permission switch of the ADB login identity can be realized. In other words, the login identity privilege escalation operation can be realized without restarting the system. This enriches the means of real vehicle fault analysis while ensuring system security, and reduces the security risks of the real vehicle system to a certain extent. Attached Figure Description

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

[0058] Figure 1 A schematic diagram of an ADB login identity switching process in the prior art provided for the embodiments of this application;

[0059] Figure 2 This application provides a schematic diagram of the structure of a system 100 for switching ADB login identity permissions.

[0060] Figure 3 A flowchart illustrating a method for switching ADB login identity permissions provided in an embodiment of this application;

[0061] Figure 4 An interactive diagram illustrating a method for switching ADB login identity permissions provided in an embodiment of this application;

[0062] Figure 5An interactive diagram illustrating another method for switching ADB login identity permissions provided in an embodiment of this application;

[0063] Figure 6 This is an interactive diagram illustrating another method for switching ADB login identity permissions provided in an embodiment of this application. Detailed Implementation

[0064] The "multiple" mentioned in the embodiments of this application refers to two or more. It should be noted that in the description of the embodiments of this application, terms such as "first" and "second" are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0065] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and specific implementation methods. It should be understood that the specific embodiments described herein are merely for explaining this application and are not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to this application are shown in the accompanying drawings, not the entire structure.

[0066] When a bug appears in a real-vehicle system, developers first conduct a detailed problem analysis to pinpoint the specific issue, then develop and verify solutions, and finally reproduce and test the bug. For a non-reproducible bug, preserving the current runtime environment is crucial for bug resolution throughout the entire bug-fixing process.

[0067] Bug analysis often employs methods such as system log analysis and importing or executing tools. These analytical methods require developers to have certain read, import, and execute permissions on the actual vehicle system files.

[0068] Currently, in real-world vehicle systems, to ensure the security of system resources and vehicle operational data, ADB is configured to start by default as a regular user shell account to prevent unauthorized users from modifying system data as super administrators. Shell accounts cannot modify default system configurations, import or execute testing tools, or even access certain operational status information, which significantly impacts problem analysis. Therefore, when encountering issues with the vehicle system after logging in as a shell account, it is necessary to switch to the super administrator (root) account. Root access allows for access to higher-level files and uses higher-level privileges to investigate the cause of the problem.

[0069] For traditional ADB login identity management methods, switching the login identity to the root user requires restarting the system and modifying the configuration. See [link to documentation] for details. Figure 1The diagram illustrates a flow chart of ADB login identity switching in the prior art. However, once the system restarts, the current operating environment will no longer exist, and for some sporadic problems, it will be difficult to reproduce after a restart. Researchers can only analyze the problem through logs, limiting analytical methods, hindering the modification and verification process, preventing the problem from being truly analyzed and resolved, and leaving potential hazards in real vehicles.

[0070] Based on this, this application provides a method for switching ADB login identity permissions, applied to an ECU, which communicates with a host computer. The method involves receiving a connection request message and obtaining the target permission indicated by the connection request message. The connection request message is sent by the host computer to the ECU in response to a permission switching instruction. The permission switching instruction instructs the host computer to switch the ADB login identity permission to the target permission. The target permission includes ordinary permission or administrator permission. If the target permission is administrator permission, a first message is sent to the host computer. A first signature information message is received, carrying first signature information. The first signature information is obtained by the host computer signing the first message using the target private key. The host computer's identity is verified based on the first signature information, and an identity verification result is obtained. After the identity verification result indicates that the host computer's identity verification is successful, the legality of the host computer's signature information is verified. If the host computer's signature information is legal, a first connection request response message is sent to the host computer, indicating that the host computer is allowed to switch the ADB login identity permission to administrator permission.

[0071] Thus, in the method provided in this application embodiment, based on receiving the first signature information message, and under the condition that the host computer identity verification is passed and the host computer signature information is verified to be legal, the permission switch of the ADB login identity is realized. That is, the login identity privilege escalation operation can be realized without restarting the system. Under the premise of ensuring system security, the means of real vehicle fault analysis are enriched, and the security risks of the real vehicle system are reduced to a certain extent.

[0072] To facilitate understanding of the specific implementation of the method for switching ADB login identity permissions provided in the embodiments of this application, the following description will be provided in conjunction with the accompanying drawings.

[0073] It should be noted that the entity implementing the method for switching ADB login identity permissions can be the system for switching ADB login identity permissions provided in this application embodiment. This system can be carried within an electronic device or a functional module of an electronic device. The electronic device in this application embodiment can be any device capable of implementing the business standardization method in this application embodiment, such as an Internet of Things (IoT) device.

[0074] like Figure 2As shown, this application embodiment shows a system 100 for switching ADB login identity permissions, which can implement a method for switching ADB login identity permissions. The system 100 may include an electronic control unit (ECU) 101 and a host computer 102.

[0075] The host computer 102 is used to send a connection request message to the ECU 101 in response to a permission switching command; the connection request message is used to indicate the target permission; the permission switching command indicates to switch the permission of the ADB login identity to the target permission; the target permission includes ordinary permission or administrator permission;

[0076] ECU101 is used to receive connection request messages and obtain the target permissions indicated by the connection request message;

[0077] ECU101 is also used to send a first message to the host computer if the target permission is the administrator permission;

[0078] The host computer 102 is also used to receive the first message and send the first signature information message to the ECU; the first signature information message carries first signature information; the first signature information is obtained by the host computer after signing the first message using the target private key;

[0079] ECU101 is also used to perform identity verification on the host computer based on the first signature information and obtain the identity verification result;

[0080] ECU101 is also used to verify the legality of the signature information of the host computer after the identity verification result indicates that the identity verification of the host computer has passed;

[0081] ECU101 is also used to send a first connection request response message to the host computer if the signature information of the host computer is valid. The first connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to the administrator permissions.

[0082] The host computer 102 is also used to switch the permissions of the ADB login identity to the administrator permissions after receiving the first connection request response message.

[0083] In this embodiment, the vehicle system defaults to shell user login to ensure the security and privacy of the vehicle system and data. Under the premise of normal operation of the vehicle system, privilege escalation operations are allowed on some trusted devices. Authenticated personnel and devices can log in as root, ensuring convenience for problem analysis and enabling more effective debugging and repair methods. The entire identity login switching process is fully automated, ensuring the normal operation of the vehicle system, protecting the problem scene, and facilitating more efficient analysis, location, and resolution of issues.

[0084] Figure 3 This is a flowchart illustrating a method for switching ADB login identity permissions according to an embodiment of this application. The ECU can be ECU101 in the system 100 for switching ADB login identity permissions. The ECU communicates with a host computer, which can be host computer 102 in the system 100 for switching ADB login identity permissions. To facilitate understanding of the solution provided in this application, the following embodiments will describe the interaction process between ECU101 and host computer 102, where S11 to S16 are the steps executed by ECU101, and S01 to S03 are the steps executed by host computer 102.

[0085] In this embodiment of the application, the following steps may be included, for example:

[0086] S01, in response to the permission switching command, the host computer 102 sends a connection request message to the ECU 101.

[0087] S11, ECU101 receives the connection request message and obtains the target permissions indicated by the connection request message.

[0088] It should be noted that the connection request message is sent by the host computer to the ECU in response to the permission switching command; the permission switching command instructs the host computer to switch the permissions of the ADB login identity to the target permissions; the target permissions include ordinary permissions or administrator permissions.

[0089] In the actual implementation, connection request messages can be represented by CONNECT messages, shell indicates normal privileges, and root indicates administrator privileges.

[0090] Because the operating principle of ADB is based on the connection between the ADB server of the host computer and the daemon process Adbd of the ECU. The ADB client of the host computer forwards commands through the ADB server, and Adbd accepts, parses and runs the command line. In the specific implementation process, the host computer can be, for example, a personal computer (PC), and the ECU can be, for example, an ECU representing the actual vehicle system.

[0091] S12, if the target has administrator privileges, ECU101 sends the first message to the host computer 102.

[0092] S02, the host computer 102 sends a first signature information message to the ECU 101 so that the ECU 101 can verify the identity of the host computer 102 and verify the legality of the signature information of the host computer 102 based on the first signature information.

[0093] It should be noted that the first message indicates that the ECU has received a connection request message. The first message can be, for example, a randomly generated authentication token (TOKEN).

[0094] In the specific implementation process, the host computer connects to the ECU, and the ECU sends an AUTH TOKEN message to the host computer, which contains a 20-byte random number TOKEN.

[0095] S13, ECU101 receives the first signature information message, which carries the first signature information.

[0096] It should be noted that the first signature information is obtained by the host computer after signing the first message using the target private key.

[0097] In the specific implementation process, the host computer uses its own target private key to sign the random number TOKEN and puts it in the SIGNATURE message (i.e. the first signature information message) sent to the ECU.

[0098] In one possible implementation, the target private key is generated by the host computer based on the RSA (Rivest-Shamir-Adleman) encryption algorithm. Therefore, the method provided in this application embodiment may further include:

[0099] The host computer 102 uses the RSA encryption algorithm to generate a key pair, which includes an initial private key and an initial public key; the initial public key is generated based on the initial private key.

[0100] The host computer 102 saves the initial private key as the target private key;

[0101] The host computer 102 packages and encodes the initial public key according to a preset format to obtain the encoded initial public key;

[0102] The host computer 102 generates a target public key based on the host computer's device identifier and the encoded initial public key. The target public key corresponds to the target private key. The device identifier includes the username of the login identity and the computer name of the host computer.

[0103] RSA encryption is an asymmetric encryption algorithm used to generate key pairs. The private key is used for encryption and signing, and the public key is used for decryption and signature verification.

[0104] As an example, in the specific implementation process, when the ADB.exe process is started on the host computer, a key pair will be generated locally. For example, the key pair is generated using the RSA encryption algorithm, and the initial private key is saved as the target private key. The initial private key is usually obtained by multiplying two large prime numbers. The initial private key is kept secret, and only the person holding the initial private key can encrypt and sign.

[0105] The initial public key is composed of a portion of the initial private key, which can be calculated, for example, based on the mathematical properties of the initial private key. In the specific implementation, the target public key consists of two parameters: the modulus and the exponent. The modulus is part of the initial private key and is the product of two large prime numbers, while the exponent is a small integer.

[0106] The generated target public key can be used to verify the authenticity of data signed with the target private key. The initial public key is usually encoded in a standard preset format (such as Base64 encoding format), and then packaged into Privacy-Enhanced Mail (PEM) format or Distinguished Encoding Rules (DER) format to generate the encoded initial public key.

[0107] The target public key is generated by combining the encoded initial public key, the username of the current ADB login identity on the host computer, and the computer name of the host computer.

[0108] Among them, the RSA encryption algorithm can be, for example, the RSA1024 encryption algorithm, which refers to the RSA encryption algorithm using a 1024-bit key length. In asymmetric encryption, the longer the key length, the higher the security. With the improvement of computing power, the RSA2048 encryption algorithm can also be used, for example. This application does not impose specific limitations on the RSA encryption algorithm.

[0109] It should be noted that in this embodiment, the host computer information, including the username and computer name, is automatically obtained when the key pair is generated, effectively binding the key pair to the host computer. This part combines ADB native logic. Reusing this ADB native logic also ensures that the host computer's connection to other devices is not affected.

[0110] S14, ECU101 performs identity verification on the host computer based on the first signature information and obtains the identity verification result.

[0111] In this embodiment of the application, the host computer performs identity verification based on the first signature information to obtain the identity verification result, which includes identity verification passed or identity verification failed.

[0112] S15, after the identity verification result indicates that the identity verification of the host computer 102 has passed, ECU101 verifies the legality of the signature information of the host computer 102.

[0113] S16, if the signature information of the host computer 102 is valid, ECU101 sends a first connection request response message to the host computer 102.

[0114] It should be noted that the first connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to the administrator permissions.

[0115] S03, after receiving the first connection request response message, the host computer 102 switches the ADB login identity's permissions to administrator permissions.

[0116] In one possible implementation, the method provided in this application embodiment may further include:

[0117] If the signature information of the host computer is invalid, a second connection request response message is sent to the host computer.

[0118] The second connection request response message indicates that the host computer is not allowed to switch the ADB login identity's permissions to administrator permissions, meaning that it should still perform the corresponding operations with normal permissions.

[0119] In the specific implementation process, the login identity permissions are usually ordinary permissions. When the developers detect a bug, the ordinary permissions can be elevated to administrator permissions using the method provided in this application embodiment. After the bug is fixed, the administrator permissions can be reduced back to ordinary permissions using the method provided in this application embodiment. In this way, the login identity privilege escalation operation can be achieved without restarting the system. This enriches the means of real vehicle fault analysis while ensuring system security and reduces the security risks of the real vehicle system to a certain extent.

[0120] It should be noted that elevating ordinary privileges to administrator privileges is divided into the first privilege escalation and the second privilege escalation.

[0121] First, the embodiments of this application will be described in conjunction with the specific implementation process of the first privilege escalation. The ECU may include Adbd and a framework, and the host computer may include an ADB server and an ADB client. Adbd is a daemon process running on the ECU, responsible for handling all commands from ADB. In the specific implementation process, developers input corresponding instructions through the ADB client, and the ADB server receives the instructions sent by the ADB client and interacts with the ECU's Adbd.

[0122] Please see Figure 4This is an interactive diagram illustrating a method for switching ADB login identity permissions provided in an embodiment of this application. In one embodiment of this application, the method may include, for example, the following steps:

[0123] S11, Receive connection request message and obtain the target permissions indicated by the connection request message.

[0124] It should be noted that the connection request message is sent by the host computer to the ECU in response to the permission switching command; the permission switching command instructs the host computer to switch the permissions of the ADB login identity to the target permissions; the target permissions include ordinary permissions or administrator permissions, and the connection request message can be represented by, for example, a CONNECT message.

[0125] S12, if the target has administrator privileges, send the first message to the host computer.

[0126] In the specific implementation process, the ECU sends the first AUTHTOKEN message to the host computer, which contains a 20-byte random number TOKEN.

[0127] S13, Receive the first signature information message, the first signature information message carries the first signature information.

[0128] It should be noted that the first signature information is obtained by the host computer after signing the first message using the target private key.

[0129] In the specific implementation process, the host computer uses its own target private key to sign the random number TOKEN and puts it in the first signature information message (e.g., represented by a SIGNATURE message) sent to the ECU.

[0130] S14, verify the identity of the host computer based on the first signature information and obtain the identity verification result.

[0131] In one possible implementation, S4 provided in this application embodiment may include:

[0132] S1411, if there is no pre-stored public key that matches the first signature information, the first identity verification result indicates that the host computer's identity verification failed.

[0133] It should be noted that the ECU checks the signature. If it is correct, it responds with a CONNECT message; otherwise, it sends a new AUTH TOKEN message to the ECU, providing a new random number.

[0134] It should be noted that since the ECU is receiving the message from the host computer for the second time, and the first time was the connection request message, the first identity verification result obtained here must indicate that the host computer's identity verification failed because the target public key of the ECU has not been obtained. In other words, step S412 needs to be executed.

[0135] S1412, send the second message to the host computer.

[0136] In the specific implementation process, the ECU sends a second AUTH TOKEN message to the host computer.

[0137] The host computer receives the second AUTHTOKEN message and sends an AUTH RSAPUBLICKEY message to the ECU. The AUTHRSAPUBLICKEY message contains the host computer's target public key.

[0138] S1413, save the target public key sent by the host computer. The target public key corresponds to the target private key.

[0139] Upon receiving the target public key, the ECU saves the target public key sent by the host computer.

[0140] In the native ADB authentication logic of existing technology, the ECU's Adbd will send the host computer's target public key to the ECU's framework, which will pop up a message box asking whether to allow (or permanently allow) the host computer to use the Universal Serial Bus (USB) debugging interface, that is, whether to add it to the trust list.

[0141] In this embodiment, the framework outputs the host computer information of the connector in the native ADB authentication logic, replacing the user's manual confirmation process in the prior art with automatic saving for subsequent verification. This design provides the possibility of ADB two-way authentication for ECU devices that do not have interactive capabilities.

[0142] S1414, send the third message to the host computer.

[0143] In the specific implementation process, the ECU sends a third AUTHTOKEN message to the host computer, which contains a random number TOKEN.

[0144] The host computer uses its own target private key to sign the random number TOKEN and places it in a second signature information message (e.g., represented by a SIGNATURE message) sent to the ECU.

[0145] S1415, Receive the second signature information message.

[0146] The second signature information message carries the second signature information, which is obtained by the host computer after signing the third message using the target private key.

[0147] S1416, verify the identity of the host computer based on the target public key to obtain the second identity verification result.

[0148] In one possible implementation, S416 provided in this application embodiment may include: extracting the host computer's device identifier from the target public key; comparing the device identifier with device information in a preset whitelist to obtain a second identity verification result. The device identifier includes the username of the logged-in user and the computer name of the host computer.

[0149] It should be noted that developers will integrate the information of devices that are allowed to access the host computer into the actual vehicle system in the form of a whitelist. In the specific implementation process, the username@computer name of the host computer will be extracted from the target public key and compared with the device information in the preset whitelist. If the comparison is successful, it proves that it is a trusted device, that is, it passes the identity verification. In the subsequent secondary privilege escalation process, the pre-stored public key (the target public key that has passed the identity verification) can be obtained to directly verify the signature information to obtain the legitimacy of the signature information.

[0150] S1417, the identity verification result obtained is the second identity verification result.

[0151] S15: After the identity verification result indicates that the host computer's identity verification has passed, verify the legality of the host computer's signature information.

[0152] In one possible implementation, S15 provided in this application embodiment may include: after the identity verification result indicates that the identity verification of the host computer has passed, extracting the target public key information of the target public key from the target public key; and verifying the legality of the second signature information based on the target public key information.

[0153] S16, if the signature information of the host computer is valid, send the first connection request response message to the host computer.

[0154] It should be noted that the first connection request response message indicates that the host computer is allowed to switch the ADB login identity's permissions to administrator permissions.

[0155] In this embodiment, users log in to the system with default shell privileges to ensure the security and privacy of the vehicle system and data. Through authenticated personnel login and access to the host computer device, login with root administrator privileges is supported, ensuring ease of bug analysis in the vehicle system and enabling more effective debugging and repair methods. Thus, the method provided in this embodiment allows for privilege escalation operations by trusted devices while the vehicle system is running normally. The entire login identity switching process is fully automated, allowing for rapid switching of login identity permissions without restarting the system, protecting the environment in which problems occur in the vehicle system, and enabling more efficient analysis, location, and resolution of problems.

[0156] Next, the embodiments of this application will be described in conjunction with the specific implementation process of weight reduction.

[0157] Please see Figure 5 This is an interactive diagram illustrating a method for switching ADB login identity permissions provided in an embodiment of this application. In embodiment two of this application, the following steps may be included, for example:

[0158] S11, Receive connection request message and obtain the target permissions indicated by the connection request message.

[0159] It should be noted that the connection request message is sent by the host computer to the ECU in response to the permission switching command; the permission switching command instructs the host computer to switch the permissions of the ADB login identity to the target permissions; the target permissions include ordinary permissions or administrator permissions, and the connection request message can be represented by, for example, a CONNECT message.

[0160] In this embodiment of the application, since the administrator privileges are to be switched to ordinary privileges, the target privileges are ordinary privileges.

[0161] S12, if the target permission is normal permission, send a third connection request response message to the host computer.

[0162] The third connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to normal permissions.

[0163] In this embodiment of the application, after receiving a connection request message that switches the target's permissions from administrator permissions to ordinary permissions, the permission reduction can be achieved without corresponding identity verification and signature validity verification.

[0164] Finally, the embodiments of this application will be described in conjunction with the specific implementation process of the second privilege escalation (the second and subsequent times). In the second privilege escalation process, since the target public key after identity verification has already been saved in the first privilege escalation process, that is, the host machine's identity verification has passed and it is an recognized host machine capable of switching identity permissions, the legality of the first signature information can be directly verified by the pre-stored public key.

[0165] Please see Figure 6 This is an interactive diagram illustrating a method for switching ADB login identity permissions provided in an embodiment of this application. In embodiment three, for example, the following steps may be included:

[0166] S11, Receive connection request message and obtain the target permissions indicated by the connection request message.

[0167] It should be noted that the connection request message is sent by the host computer to the ECU in response to the permission switching command; the permission switching command instructs the host computer to switch the permissions of the ADB login identity to the target permissions; the target permissions include ordinary permissions or administrator permissions, and the connection request message can be represented by, for example, a CONNECT message.

[0168] In this embodiment of the application, since the goal is to switch from ordinary permissions to administrator permissions, the target permission is administrator permissions.

[0169] S12, if the target has administrator privileges, send the first message to the host computer.

[0170] In the specific implementation process, the ECU sends the first AUTHTOKEN message to the host computer, which contains a 20-byte random number TOKEN.

[0171] S13, Receive the first signature information message, the first signature information message carries the first signature information.

[0172] It should be noted that the first signature information is obtained by the host computer after signing the first message using the target private key.

[0173] In the specific implementation process, the host computer uses its own target private key to sign the random number TOKEN and puts it in the first signature information message (e.g., represented by a SIGNATURE message) sent to the ECU.

[0174] Since a key pair, namely the target private key and the target public key, has already been generated during the first privilege escalation process, there is no need to generate a key pair again for the host computer if it is not disconnected from the ECU and is not powered off.

[0175] S14, verify the identity of the host computer based on the first signature information and obtain the identity verification result.

[0176] In one possible implementation, S4 provided in this application embodiment may include:

[0177] S1421, if a pre-stored public key that matches the first signature information exists, the first identity verification result is obtained, indicating that the host computer's identity verification is successful; the pre-stored public key is stored after identity verification.

[0178] It should be noted that in this embodiment of the application, the target public key stored after identity verification during the first privilege escalation process is a pre-stored public key. If the pre-stored public key that matches the first signature information exists, it proves that the host computer is a trusted device, and the corresponding signature legality verification can be performed according to the corresponding first signature information.

[0179] In this embodiment, the target public key from the first privilege escalation needs to be obtained if the ECU is powered on. If the ECU is powered off and restarted, the target public key from the first privilege escalation will not exist, meaning there is no pre-stored public key.

[0180] S1422, the identity verification result obtained is the first identity verification result.

[0181] S15: After the identity verification result indicates that the host computer's identity verification has passed, verify the legality of the host computer's signature information.

[0182] In one possible implementation, S15 provided in this application embodiment may include: after the identity verification result indicates that the identity verification of the host computer has passed, extracting the pre-stored public key information of the pre-stored public key; and verifying the legality of the first signature information based on the pre-stored public key information.

[0183] S16, if the signature information of the host computer is valid, send the first connection request response message to the host computer.

[0184] It should be noted that the first connection request response message indicates that the host computer is allowed to switch the ADB login identity's permissions to administrator permissions.

[0185] It should be noted that in the above embodiments one to three, a new login is required for the privilege escalation or demotion to take effect; in the specific implementation process, adb unroot is the demotion command, adb root is the privilege escalation command, and adb shell is the login command.

[0186] Furthermore, the processes described in Embodiments 1 to 3 above are automatic interactions during the ADB connection process, requiring no human intervention. The ADB server on the host computer all uses native ADB logic without any modifications, thus ensuring compatibility between the ADB server and different ECUs.

[0187] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that all or part of the steps in the methods of the above embodiments can be implemented by means of software plus a general-purpose hardware platform. Based on this understanding, the technical solution of this application can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as a read-only memory (ROM) / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, a server, or a network communication device such as a router) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0188] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on its differences from other embodiments. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. The device embodiments described above are merely illustrative. Modules described as separate components may or may not be physically separate. Components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the objectives of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0189] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for switching ADB login identity permissions, characterized in that, Applied to an electronic control unit (ECU), wherein the ECU is communicatively connected to a host computer, the method includes: Receive a connection request message and obtain the target permission indicated by the connection request message; the connection request message is sent by the host computer to the ECU in response to a permission switching instruction; the permission switching instruction instructs the host computer to switch the permissions of the ADB login identity to the target permission; the target permission includes ordinary permissions or administrator permissions; If the target permission is the administrator permission, send the first message to the host computer; Receive a first signature information message, the first signature information message carrying first signature information; the first signature information is obtained by the host computer after signing the first message using the target private key; The host computer is authenticated based on the first signature information to obtain an authentication result; wherein, the authentication of the host computer based on the first signature information to obtain an authentication result includes: if no pre-stored public key matching the first signature information exists, a first authentication result is obtained indicating that the authentication of the host computer has failed; a second message is sent to the host computer; the target public key sent by the host computer is saved, the target public key corresponding to the target private key; a third message is sent to the host computer; a second signature information message is received; the second signature information message carries second signature information, wherein... The second signature information is obtained by the host computer signing the third message using the target private key; the host computer is verified for identity based on the target public key to obtain a second identity verification result; the identity verification result is the second identity verification result; the step of verifying the host computer for identity based on the target public key to obtain the second identity verification result includes: extracting the device identifier of the host computer from the target public key, the device identifier including: the username of the login identity and the computer name of the host computer; comparing the device identifier with the device information in the preset whitelist to obtain the second identity verification result; After the identity verification result indicates that the host computer's identity verification has passed, the legality of the host computer's signature information is verified. If the signature information of the host computer is valid, a first connection request response message is sent to the host computer. The first connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to the administrator permissions.

2. The method according to claim 1, characterized in that, The step of verifying the identity of the host computer based on the first signature information and obtaining the identity verification result includes: If a pre-stored public key that matches the first signature information exists, then the first identity verification result indicates that the identity verification of the host computer has passed; the pre-stored public key is stored after identity verification. The identity verification result obtained is the first identity verification result.

3. The method according to claim 2, characterized in that, After the identity verification result indicates that the host computer's identity verification has passed, verifying the legality of the host computer's signature information includes: After the identity verification result indicates that the host computer has passed the identity verification, the pre-stored public key information of the pre-stored public key is extracted; The legitimacy of the first signature information is verified based on the pre-stored public key information.

4. The method according to claim 1, characterized in that, After the identity verification result indicates that the host computer's identity verification has passed, verifying the legality of the host computer's signature information includes: After the identity verification result indicates that the host computer has passed the identity verification, the target public key information of the target public key is extracted from the target public key; The legitimacy of the second signature information is verified based on the target public key information.

5. The method according to claim 1, characterized in that, The method further includes: If the signature information of the host computer is invalid, a second connection request response message is sent to the host computer. The second connection request response message indicates that the host computer is not allowed to switch the permissions of the ADB login identity to the administrator permissions.

6. A method for switching ADB login identity permissions, characterized in that, Applied to a host computer, wherein the host computer communicates with an electronic control unit (ECU), the method includes: In response to a permission switching command, a connection request message is sent to the ECU; the connection request message is used to indicate the target permission; the permission switching command indicates that the permissions of the ADB login identity be switched to the target permission; the target permission includes ordinary permissions or administrator permissions; The system receives a first message and sends a first signature information message to the ECU, so that the ECU can perform identity verification on the host computer and verify the legality of the host computer's signature information based on the first signature information. The first message is sent by the ECU to the host computer after obtaining the target permission as administrator. The first signature information message carries first signature information. The first signature information is obtained by the host computer after signing the first message using the target private key. The step of verifying the host computer's identity based on the first signature information includes: if no pre-stored public key matching the first signature information exists, obtaining a first identity verification result indicating that the host computer's identity verification failed; sending a second message to the host computer; and saving the target public key sent by the host computer. The target public key corresponds to the target private key; a third message is sent to the host computer; a second signature information message is received; the second signature information message carries second signature information, which is obtained by the host computer after signing the third message using the target private key; the host computer is verified for identity based on the target public key to obtain a second identity verification result; the identity verification result is the second identity verification result; the step of verifying the host computer for identity based on the target public key to obtain the second identity verification result includes: extracting the device identifier of the host computer from the target public key, the device identifier including: the username of the login identity and the computer name of the host computer; comparing the device identifier with device information in a preset whitelist to obtain the second identity verification result; Upon receiving the first connection request response message, the permissions of the ADB login identity are switched to the administrator permissions; the first connection request response message is sent by the ECU after the identity verification of the host computer is passed and the signature information of the host computer is valid, and the first connection request response message indicates that the permissions of the ADB login identity are allowed to be switched to the administrator permissions.

7. The method according to claim 6, characterized in that, The method further includes: A key pair is generated using the RSA encryption algorithm, the key pair including an initial private key and an initial public key; the initial public key is generated based on the initial private key. Save the initial private key as the target private key; The initial public key is packaged and encoded according to a preset format to obtain the encoded initial public key; A target public key is generated based on the device identifier of the host computer and the encoded initial public key, and the target public key corresponds to the target private key; the device identifier includes the username of the ADB login identity and the computer name of the host computer.

8. A system for switching ADB login identity permissions, characterized in that, The system includes an electronic control unit (ECU) and a host computer; The host computer is used to send a connection request message to the ECU in response to a permission switching command; the connection request message is used to indicate the target permission; the permission switching command indicates to switch the permission of the ADB login identity to the target permission; The target permissions include normal permissions or administrator permissions; The ECU is configured to receive the connection request message and obtain the target permission indicated by the connection request message; The ECU is further configured to send a first message to the host computer if the target permission is the administrator permission; The host computer is also used to receive the first message and send a first signature information message to the ECU; the first signature information message carries first signature information; the first signature information is obtained by the host computer after signing the first message using the target private key; The ECU is further configured to perform identity verification on the host computer based on the first signature information and obtain an identity verification result; wherein, the step of performing identity verification on the host computer based on the first signature information and obtaining an identity verification result includes: if no pre-stored public key matching the first signature information exists, obtaining a first identity verification result indicating that the identity verification of the host computer has failed; sending a second message to the host computer; saving the target public key sent by the host computer, the target public key corresponding to the target private key; sending a third message to the host computer; receiving a second signature information message; the second signature information message carrying a second signature information The second signature information is obtained by the host computer signing the third message using the target private key; the host computer is verified for identity based on the target public key to obtain a second identity verification result; the identity verification result is the second identity verification result; the step of verifying the host computer for identity based on the target public key to obtain the second identity verification result includes: extracting the device identifier of the host computer from the target public key, the device identifier including: the username of the login identity and the computer name of the host computer; comparing the device identifier with device information in a preset whitelist to obtain the second identity verification result; The ECU is also used to verify the legality of the signature information of the host computer after the identity verification result indicates that the identity verification of the host computer has passed; The ECU is further configured to send a first connection request response message to the host computer if the signature information of the host computer is valid. The first connection request response message indicates that the host computer is allowed to switch the permissions of the ADB login identity to the administrator permissions. The host computer is also configured to switch the permissions of the ADB login identity to the administrator permissions after receiving the first connection request response message.

Images