Debugging method and device, electronic equipment and vehicle

Abstract

The application relates to a debugging method and device, electronic equipment and a vehicle, and relates to the technical field of security authentication, and at least solves the technical problem that the security of security authentication of a user accessing a vehicle-mounted device is poor in a scene of debugging the vehicle-mounted device in related technologies. The method comprises the following steps: obtaining login information input by a user, wherein the login information comprises account information and key information; performing security authentication on the key information, wherein the security authentication is used for verifying whether the user has a debugging permission for the vehicle-mounted device; in the case that the key information passes the security authentication, determining a target permission range of the user for debugging the vehicle-mounted device based on the login information, wherein different login information corresponds to different permission ranges; and responding to or rejecting a debugging instruction within the target permission range. The application is used for improving the security of security authentication of a user accessing a vehicle-mounted device.

Description

Technical Field

[0001] This application relates to the field of security authentication technology, specifically to a debugging method, device, electronic equipment, and vehicle. Background Technology

[0002] With the continuous development of vehicle intelligence, Android Debug Bridge (ADB) has become a mainstream debugging interface widely used in the development of intelligent connected vehicles and IoT devices for communication and control between embedded systems, in-vehicle intelligent terminals, and Android platform devices. While ADB debugging tools provide convenience for development, testing, and remote maintenance, they also expose significant system security risks. In particular, weak authorization mechanisms and lax permission management during debugging make them vulnerable to becoming entry points for attackers to gain control of vehicle devices.

[0003] In related technologies, the process of authenticating users accessing in-vehicle devices using static password mechanisms is relatively fixed, making it easy for attackers to capture authentication passwords. Furthermore, traditional authentication algorithms are complex and unsuitable for the low latency and high stability requirements of in-vehicle devices. Therefore, current methods for authenticating users accessing in-vehicle devices during debugging scenarios offer poor security. Summary of the Invention

[0004] This application provides a debugging method, apparatus, electronic device, and vehicle to at least solve the technical problem of poor security in the related art when performing security authentication on users debugging in-vehicle equipment. The technical solution of this application is as follows:

[0005] According to a first aspect of this application, a debugging method is provided, the method comprising: obtaining login information input by a user, the login information including account information and key information; performing security authentication on the key information, the security authentication being used to verify whether the user has debugging permissions for the vehicle-mounted device; if the key information passes security authentication, determining the target permission range for the user to debug the vehicle-mounted device based on the login information, different login information corresponding to different permission ranges, the target permission range being determined based on any one of the following: account information, the user's target role level determined by the account information, or the indication information determined in the key information; and responding to or rejecting debugging commands within the target permission range.

[0006] Based on the aforementioned technical means, in scenarios involving debugging in-vehicle devices, this application can securely authenticate the key information in the user's login information. If the user is verified to have debugging permissions for the in-vehicle device, the application can further determine the user's target permission range for debugging the in-vehicle device based on the login information. The in-vehicle device can then respond to or reject the user's debugging command within the user's corresponding target permission range. Thus, when different users debug in-vehicle devices using different login information, the permission range for each user can be determined, allowing users to debug the in-vehicle device only within their permitted permission range. This prevents users from exceeding their permissions and ensures the security of user authentication for debugging in-vehicle devices.

[0007] In one possible implementation, the target permission range is used to indicate the maximum number of executions; the above-mentioned response to or rejection of debugging instructions within the target permission range includes: in response to obtaining a new debugging instruction, determining the number of times the debugging instruction has been executed in the historical time period before the current moment; if the number of executions is less than the maximum number of executions, responding to the new debugging instruction; if the number of executions is greater than or equal to the maximum number of executions, rejecting the new debugging instruction.

[0008] Based on the aforementioned technical means, this application can constrain a user's debugging permissions for in-vehicle equipment by setting a maximum number of executions. Upon receiving a new debugging command, the system assesses the command to determine the number of debugging commands executed within the historical time period prior to the current moment. A new debugging command is only responded to if the number of previously executed commands is less than the set maximum; otherwise, the new command is rejected if the number of previously executed commands is greater than or equal to the set maximum. Thus, by setting a maximum number of executions to limit the number of times a user can debug in-vehicle equipment within a certain time period, frequent debugging by the user can be avoided, which could affect the performance or safety of the in-vehicle equipment.

[0009] In one possible implementation, the target permission range is used to indicate the maximum instruction input rate; the above-mentioned response to or rejection of debugging instructions within the target permission range includes: in response to obtaining a new debugging instruction, determining the instruction input rate within a historical time period prior to the current moment; responding to the new debugging instruction if the instruction input rate is less than or equal to the maximum instruction input rate; and rejecting the new debugging instruction if the instruction input rate is greater than the maximum instruction input rate.

[0010] Based on the aforementioned technical means, this application can constrain a user's debugging permissions for in-vehicle equipment by setting a maximum command input rate. Upon receiving a new debugging command, the system assesses the command input rate over a historical period prior to the current moment. The new debugging command is only responded to if its input rate is less than or equal to the set maximum; otherwise, it is rejected. By setting a maximum command input rate to constrain the user's debugging rate for the in-vehicle equipment within a certain timeframe, multiple debugging commands issued rapidly by the user can be prevented, thus avoiding situations where the in-vehicle equipment cannot process a large number of commands in a short period and may malfunction.

[0011] In one possible implementation, the target permission range is used to indicate the instruction whitelist and / or instruction blacklist; the above-mentioned response to or rejection of debugging instructions within the target permission range includes: in response to obtaining a new debugging instruction, detecting whether the new debugging instruction is in the instruction blacklist and / or instruction whitelist; if the new debugging instruction is in the instruction blacklist, rejecting the new debugging instruction; if the new debugging instruction is in the instruction whitelist, responding to the new debugging instruction.

[0012] Based on the aforementioned technical means, this application can restrict user debugging permissions for in-vehicle equipment by setting a command whitelist and / or command blacklist. Upon receiving a new debugging command, the system judges whether the new command is in the command blacklist and / or command whitelist. Debugging commands in the command blacklist are rejected, while those in the command whitelist are accepted. Thus, by determining whether a new debugging command is in the command blacklist and / or command whitelist, the legitimacy of obtaining a new debugging command is determined, thereby improving the security of the debugging process for in-vehicle equipment.

[0013] In one possible implementation, the target permission range is used to indicate secondary permission authentication during debugging; the above-mentioned response to or rejection of debugging instructions within the target permission range includes: in response to receiving a new debugging instruction, obtaining first authentication information input by the user, the first authentication information being used to perform secondary authentication on the user; if the first authentication information passes authentication, responding to the new debugging instruction; if the first authentication information fails authentication, rejecting the new debugging instruction.

[0014] Based on the aforementioned technical means, this application can limit the accuracy of user debugging of in-vehicle equipment by setting a secondary authentication restriction during debugging. Upon receiving a new debugging command, a secondary authentication is performed on the user to verify the initial authentication information entered by the user. The new debugging command is only responded to if the initial authentication information is successfully authenticated; otherwise, the new debugging command is rejected. Thus, by setting a secondary authentication restriction to determine the legitimacy of the user's debugging command, the security of the debugging process for in-vehicle equipment can be further improved.

[0015] In one possible implementation, the above-mentioned determination of the target permission range for a user to debug the vehicle-mounted equipment based on login information includes: determining the permission range corresponding to the user's target role level based on account information, where different role levels correspond to different permission ranges, and the target role level is any one of the following: debugging equipment personnel, maintenance equipment personnel, or development equipment personnel. Different users corresponding to the same role level have different levels, and users at different levels have different target permission ranges; and determining the target permission range within the permission range corresponding to the user's target role level based on key information.

[0016] Based on the aforementioned technical means, this application can directly determine the user's target role level's corresponding permission scope based on the user's account information in the login information, and then determine the target permission scope within the permission scope corresponding to the user's target role level based on the key information. Thus, by using the user's target role level indicated by the account information, the permission scope corresponding to that target role level can be determined first. Then, based on the user's key information, the user's target permission scope within the determined target role level's corresponding permission scope can be further determined. Therefore, by setting different role levels corresponding to different permission scopes, the user's permission scope can be gradually and accurately determined. This avoids users exceeding their authority when debugging in-vehicle equipment, which could affect the security of the in-vehicle equipment.

[0017] In one possible implementation, the above-mentioned determination of the target permission range for a user to debug the vehicle-mounted device based on login information includes: determining the target permission range based on account information, where different account information corresponds to different permission ranges.

[0018] Based on the aforementioned technical means, this application can directly determine the target permission scope of a user based on the account information in the user's login information. Thus, by setting permission scopes corresponding to different user account information, the permission scope of each user can be accurately determined. This allows for precise restriction of user debugging permissions when debugging in-vehicle equipment, preventing users from exceeding their authority and compromising the security of the in-vehicle equipment.

[0019] In one possible implementation, the above-mentioned determination of the target permission range for a user to debug the vehicle-mounted device based on login information includes: determining the target permission range based on indication information determined from key information, the indication information being associated with the user, and the indication information being used to indicate the target permission range.

[0020] Based on the aforementioned technical means, this application can directly determine the user's target permission range based on the indication information in the user's key information. Thus, by adding user-associated indication information to the key information during key setting to indicate the user's permission range for debugging the in-vehicle device, the user's permission range can be accurately determined when the user inputs the key information. This allows for precise restriction of the user's debugging permissions when debugging the in-vehicle device, preventing unauthorized debugging that could compromise the device's security.

[0021] In one possible implementation, the key information is generated based on the identifier of the vehicle device, which includes at least one of the following: a unique identifier (UID), an electronic control unit (ECU) serial number, and a board support package (BSP) unique code.

[0022] Based on the aforementioned technical means, this application can associate the key information with the identifier of the vehicle-mounted device when setting the key information. This allows for accurate authentication of the user's key information based on the identifier of the vehicle-mounted device during user login authentication. This also prevents users without debugging privileges from debugging the vehicle-mounted device, thus ensuring its security.

[0023] In one possible implementation, the key information is generated as follows: in the case of user registration and login information, the identifier of the vehicle device is encrypted based on the encryption key to generate ciphertext; the target field is extracted from the ciphertext, and key information is generated based on the target field and a timestamp, wherein the timestamp is used to limit the validity period of the key information.

[0024] Based on the aforementioned technical means, when generating key information for user registration and login, this application can encrypt the identifier of the vehicle-mounted device using an encryption key to generate ciphertext. Then, based on the target field and timestamp extracted from the ciphertext, key information is generated. Thus, by including information related to the vehicle-mounted device's identifier in the key information, the user's key information can be associated with the vehicle-mounted device's identifier, thereby improving key security.

[0025] In one possible implementation, the above-mentioned security authentication of key information includes: encrypting the identifier of the vehicle-mounted device based on the encryption key pre-written in the vehicle-mounted device to obtain ciphertext, wherein the encryption key is written during the production and testing of the vehicle-mounted device and is in a read-only state in the vehicle-mounted device; and performing security authentication of the key information based on the target field in the ciphertext.

[0026] Based on the aforementioned technical means, this application allows for the pre-writing of encryption keys during the production and testing of in-vehicle equipment. This enables the use of the same encryption key as the generated key to encrypt the in-vehicle equipment's identifier, obtaining ciphertext. The key information is then authenticated based on the target field within the ciphertext. This method of using the same encryption key for key information authentication improves the accuracy of the authentication process. Furthermore, by setting the encryption key to read-only mode in the in-vehicle equipment, attackers can be prevented from tampering with the encryption key, further enhancing the accuracy of the authentication.

[0027] In one possible implementation, secure authentication of the key information includes: sending the key information to a server for secure authentication of the key information by the server, the server including the same encryption key as the vehicle-mounted device; and receiving the security authentication result sent by the server.

[0028] Based on the aforementioned technical means, this application can set the same encryption key as the vehicle-mounted device on the server, thereby enabling secure authentication of the key information through the server. This leverages the server's powerful data processing capabilities to improve the efficiency of security authentication.

[0029] In one possible implementation, the debugging method further includes: uploading the identifier of the vehicle device, the firmware version information of the vehicle device, and the version information of the encryption key to the server to establish a target mapping relationship on the server. The target mapping relationship is used to indicate the correspondence between the vehicle device and the encryption key, and the target mapping relationship is used by the server to perform security authentication of the key information.

[0030] Based on the aforementioned technical means, this application can establish a target mapping relationship on the server based on the identifier of the vehicle device, the firmware version information of the vehicle device, and the version information of the encryption key, so as to determine the correspondence between the vehicle device and the encryption key. This enables the server to perform accurate security authentication of the key information based on the information corresponding to the vehicle device when performing security authentication of the key information.

[0031] In one possible implementation, the debugging method further includes: acquiring debugging logs generated during the user's debugging of the vehicle-mounted device; detecting the debugging logs; and, if an abnormal operation is detected, acquiring second authentication information input by the user, wherein the abnormal operation includes at least one of the following: debugging failure frequency exceeding a preset frequency, instruction exceeding the target permission range, or instruction structure being abnormal; the second authentication information includes at least one of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, or gesture pattern, and the second authentication information is used for secondary authentication of the user; authenticating the second authentication information; and, if the second authentication information is successfully authenticated, continuing to respond to or reject debugging instructions within the target permission range.

[0032] Based on the aforementioned technical means, this application can further detect debugging logs to perform secondary authentication on users when the debugging failure frequency exceeds a preset frequency, commands exceed the target permission range, or command structure is abnormal. This further verifies the second authentication information entered by the user. Only when the second authentication information is successfully authenticated is the user allowed to continue debugging the in-vehicle device, and to continue responding to or rejecting debugging commands within the target permission range. This prevents users from exceeding their permissions to debug the in-vehicle device, or attackers from accessing the in-vehicle device, thereby improving the security of the in-vehicle device.

[0033] According to a second aspect of this application, a debugging apparatus is provided, comprising: an acquisition module, an authentication module, a determination module, and a processing module; the acquisition module is used to acquire login information input by a user, the login information including account information and key information; the authentication module is used to perform security authentication on the key information, the security authentication being used to verify whether the user has debugging permissions for the vehicle-mounted device; the determination module is used to determine the target permission range for the user to debug the vehicle-mounted device based on the login information when the key information passes security authentication, different login information corresponds to different permission ranges, and the target permission range is determined based on any one of the following: account information, the user's target role level determined by the account information, or the indication information determined in the key information; the processing module is used to respond to or reject debugging instructions within the target permission range.

[0034] In one possible implementation, the target permission range is used to indicate the maximum number of executions; the processing module is specifically used to determine the number of times the debugging instruction has been executed in the historical time period before the current moment in response to obtaining a new debugging instruction; the processing module is specifically used to respond to the new debugging instruction if the number of executions is less than the maximum number of executions; the processing module is specifically used to reject the new debugging instruction if the number of executions is greater than or equal to the maximum number of executions.

[0035] In one possible implementation, the target permission range is used to indicate the maximum instruction input rate; the processing module is specifically used to determine the instruction input rate within a historical time period prior to the current moment in response to acquiring a new debugging instruction; the processing module is specifically used to respond to the new debugging instruction if the instruction input rate is less than or equal to the maximum instruction input rate; the processing module is specifically used to reject the new debugging instruction if the instruction input rate is greater than the maximum instruction input rate.

[0036] In one possible implementation, the target permission scope is used to indicate the instruction whitelist and / or instruction blacklist; the processing module is specifically used to detect whether the new debugging instruction is in the instruction blacklist and / or instruction whitelist in response to the acquisition of a new debugging instruction; the processing module is specifically used to reject the new debugging instruction if the new debugging instruction is in the instruction blacklist; the processing module is specifically used to respond to the new debugging instruction if the new debugging instruction is in the instruction whitelist.

[0037] In one possible implementation, the target permission scope is used to indicate secondary permission authentication during debugging; the processing module is specifically used to obtain first authentication information input by the user in response to receiving a new debugging instruction, the first authentication information being used to perform secondary authentication on the user; the processing module is specifically used to respond to the new debugging instruction if the first authentication information passes authentication; the processing module is specifically used to reject the new debugging instruction if the first authentication information fails authentication.

[0038] In one possible implementation, the determining module is specifically used to determine the permission range corresponding to the user's target role level based on account information. Different role levels correspond to different permission ranges. The target role level is any one of the following: debugging equipment personnel, maintenance equipment personnel, and development equipment personnel. Different users corresponding to the same role level have different levels, and users at different levels have different determined target permission ranges. The determining module is specifically used to determine the target permission range within the permission range corresponding to the user's target role level based on key information.

[0039] In one possible implementation, the determining module is specifically used to determine the target permission range based on account information, with different account information corresponding to different permission ranges.

[0040] In one possible implementation, the determining module is specifically used to determine the target permission range based on indication information determined from the key information, the indication information being associated with a user and used to indicate the target permission range.

[0041] In one possible implementation, the key information is generated based on the identifier of the vehicle device, which includes at least one of the following: a unique identifier (UID), an electronic control unit (ECU) serial number, and a board support package (BSP) unique code.

[0042] In one possible implementation, the processing module is further configured to encrypt the identifier of the vehicle-mounted device based on the encryption key to generate ciphertext when the user registers and logs in; the processing module is further configured to extract the target field from the ciphertext and generate key information based on the target field and a timestamp, wherein the timestamp is used to limit the validity period of the key information.

[0043] In one possible implementation, the authentication module is specifically used to encrypt the identifier of the vehicle-mounted device based on the encryption key pre-written in the vehicle-mounted device to obtain ciphertext. The encryption key is written during the production and testing of the vehicle-mounted device and is in a read-only state in the vehicle-mounted device. The authentication module is specifically used to perform security authentication on the key information based on the target field in the ciphertext.

[0044] In one possible implementation, the authentication module is specifically used to send key information to the server for secure authentication of the key information by the server, the server including the same encryption key as the vehicle-mounted device; the authentication module is specifically used to receive the secure authentication result sent by the server.

[0045] In one possible implementation, the debugging device further includes: a sending module; the sending module is used to upload the identifier of the vehicle-mounted device, the firmware version information of the vehicle-mounted device, and the version information of the encryption key to the server, so as to establish a target mapping relationship on the server. The target mapping relationship is used to indicate the correspondence between the vehicle-mounted device and the encryption key, and the target mapping relationship is used by the server to perform security authentication of the key information.

[0046] In one possible implementation, the acquisition module is further configured to acquire debugging logs generated during the user's debugging of the vehicle-mounted device; the processing module is further configured to detect the debugging logs; the acquisition module is further configured to acquire second authentication information input by the user when an abnormal operation is detected, the abnormal operation including at least one of the following: the debugging failure frequency is greater than a preset frequency, the instruction exceeds the target permission range, or the instruction structure is abnormal, the second authentication information including at least one of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, or gesture pattern, the second authentication information is used for secondary authentication of the user; the processing module is further configured to authenticate the second authentication information; the processing module is further configured to continue to respond to or reject debugging instructions within the target permission range if the second authentication information is successfully authenticated.

[0047] According to a third aspect provided in this application, an electronic device is provided, comprising: a processor and a memory; wherein the memory is used to store one or more programs, the one or more programs including computer execution instructions, and when the electronic device is running, the processor executes the computer execution instructions stored in the memory, and the electronic device executes the method described in the first aspect and any possible implementation thereof.

[0048] According to the fourth aspect provided in this application, a computer-readable storage medium is provided, wherein when computer instructions stored in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device performs the method described in the first aspect and any possible implementation thereof.

[0049] According to the fifth aspect provided in this application, a computer program product is provided, the computer program product including computer instructions, which, when executed on an electronic device, cause the electronic device to perform the method described in the first aspect and any possible implementation thereof.

[0050] According to the sixth aspect provided in this application, a vehicle is provided, the vehicle including the debugging device as described in the second aspect, the vehicle being used to implement the method of the first aspect and any possible implementation thereof.

[0051] It should be noted that the technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here.

[0052] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0053] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application, and do not constitute an undue limitation of this application.

[0054] Figure 1 This is a schematic diagram of the structure of a debugging system according to an exemplary embodiment;

[0055] Figure 2 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 1 ;

[0056] Figure 3 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 2 ;

[0057] Figure 4 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 3 ;

[0058] Figure 5 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 4 ;

[0059] Figure 6 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 5 ;

[0060] Figure 7 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 6 ;

[0061] Figure 8 This is a flowchart of a debugging method according to an exemplary embodiment. Figure 7 ;

[0062] Figure 9 This is a block diagram illustrating a debugging apparatus according to an exemplary embodiment;

[0063] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment;

[0064] Figure 11 This is a schematic diagram of the structure of a computer system for an electronic device according to an exemplary embodiment. Detailed Implementation

[0065] To enable those skilled in the art to better understand the technical solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0066] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0067] The debugging method provided in this application can be applied to debugging systems. Figure 1 This is a schematic diagram illustrating the structure of a debugging system according to an exemplary embodiment. For example... Figure 1As shown, the debugging system includes: a debugging device 11, an in-vehicle device 12, and a server 13. The debugging device 11 is used to debug the in-vehicle device 12, and the server 13 is the server for the in-vehicle device 12. The server 13 can be a cloud platform server.

[0068] The debugging device 11 is used to obtain login information input by the user, including account information and key information.

[0069] The debugging device 11 is also used to perform security authentication on the key information, which verifies whether the user has debugging authority over the vehicle-mounted device 12.

[0070] The debugging device 11 is also used to determine the target permission range for the user to debug the vehicle-mounted device 12 based on the login information when the key information passes security authentication. Different login information corresponds to different permission ranges, and the target permission range is determined based on any of the following: account information, the target role level of the user determined by the account information, or the instruction information determined in the key information.

[0071] The debugging device 11 is also used to respond to or reject debugging commands within the scope of the target's permissions.

[0072] To facilitate understanding, the debugging method provided in this application will be described in detail below with reference to the accompanying drawings.

[0073] Figure 2 This is a flowchart illustrating a debugging method according to an exemplary embodiment, applied to electronic devices, such as... Figure 2 As shown, the debugging method includes the following S201-S204:

[0074] S201. Obtain the login information entered by the user.

[0075] The login information includes account information and key information.

[0076] In this embodiment, when the vehicle-mounted equipment needs to be debugged, the user (debugging personnel, maintenance personnel) can use ADB to debug the vehicle-mounted equipment for maintenance, upgrades, testing, and other debugging processes. Before debugging the vehicle-mounted equipment, the user needs to log in to the vehicle-mounted equipment using dedicated debugging information (i.e., login information). Only after the information passes security authentication will the user have the permission to debug the vehicle-mounted equipment and perform the corresponding debugging.

[0077] In one possible implementation, users can log in to the in-vehicle device using account and key information. Only after the in-vehicle device securely authenticates the account and key information, and the authentication is successful, can the user be allowed to debug the in-vehicle device. Furthermore, corresponding permission ranges can be configured for users to prevent them from unauthorized debugging of the in-vehicle device.

[0078] In one possible implementation, the user can enter account information and key information on the display interface of the debugging device, or the user can enter account information and key information on the central control screen of the vehicle device.

[0079] In some embodiments, the key information is generated based on the identifier of the vehicle device, which includes at least one of the following: a unique identifier (UID), an electronic control unit (ECU) serial number, and a board support package (BSP) unique code.

[0080] In one possible implementation, when generating key information, the identifier of the vehicle device can be used as the core parameter for generating key information, thereby ensuring that the key information corresponding to each vehicle device is non-replicable.

[0081] In one possible implementation, during the production and integration phases of the in-vehicle device, the manufacturer can embed the authentication security mechanism into the underlying hardware to ensure that the authentication data is immutable and the key cannot be exported. Specifically, this can be achieved by using an encryption key burning strategy based on the internal security area of ​​a hardware security module (e.g., a Trusted Platform Module (TPM) or Hardware Security Module (HSM)) or a System on Chip (SoC).

[0082] For example, using a controlled programming tool, the encryption key information corresponding to the cloud platform (i.e., the server) is injected into the vehicle device in a one-time write operation within a production test environment. After the key information is written, it is set to read-only mode, and physical anti-debugging mechanisms (such as fuse configuration and access address mapping) are enabled to prevent subsequent access, thereby preventing runtime or third-party devices from extracting the key information through the port. This can improve the security of the key information throughout its lifecycle.

[0083] In one possible implementation, this key information not only supports local encryption operations for the in-vehicle device but also serves as an index for the server's authentication database. Manufacturers establish a complete in-vehicle device identity database by mapping the in-vehicle device's identifier (unique production number) to the key information, thus achieving a closed loop from "hardware sequence → key binding → security authentication".

[0084] In this embodiment, the key information can be associated with the identifier of the vehicle-mounted device when setting the key information. This allows for accurate authentication of the user's key information based on the identifier of the vehicle-mounted device during user login authentication. This prevents users without debugging privileges from debugging the vehicle-mounted device, thus ensuring its security.

[0085] In some embodiments, the key information is generated in the following manner:

[0086] Given user registration and login information, the identifier of the vehicle-mounted device is encrypted using an encryption key to generate ciphertext. The target field is extracted from the ciphertext, and key information is generated based on the target field and a timestamp. The timestamp is used to limit the validity period of the key information.

[0087] In one possible implementation, the key information can be designed in the format of prefix + ciphertext digest, and the key information supports multi-version protocol identification and anti-replay mechanism.

[0088] Specifically, the "device identity registration" process can be automatically triggered when the vehicle-mounted device is first configured at the factory, registers a server account, or is first powered on and activated. During this process, the vehicle-mounted device can read its hardware identity information (i.e., the vehicle-mounted device identifier) ​​and report it to the server authentication management center via an encrypted channel. This process can also include additional information such as the vehicle-mounted device's current firmware version, key version number, and manufacturer identifier, which are used to establish a complete mapping relationship of "device identity → key identifier → encryption method" on the server.

[0089] In one possible implementation, the server encrypts the identifier of the vehicle-mounted device using AES-256 or SM4 encryption based on the registered key information, generating full-length ciphertext. Then, a specified field (i.e., the target field, such as the first 4 bytes, the last 4 bytes, or a mixture of the first and last bytes) can be extracted from the ciphertext and formatted using a standard format (e.g., hexadecimal encoding, Hex).

[0090] Specifically, the target field can be a specified field in the pre-determined ciphertext or a field in the randomly determined ciphertext.

[0091] In one possible implementation, the timestamp can be a timestamp generated based on the time when the key information was generated.

[0092] In one possible implementation, the complete key information can be further composed in the format of "version identifier_ciphertext_timestamp", for example, the key information is "SEC_3F4A1C2B_20250601", and the key information supports expiration judgment and authentication tracking.

[0093] In one possible implementation, the key information also supports a storage and rotation mechanism. That is, the key information establishes a two-way mapping relationship with the identifier of the vehicle device and is stored in the server's database. This allows for automatic rotation based on time / event-driven principles to change the key information, such as monthly, every time the vehicle device is restarted, or after authentication failure.

[0094] In one possible implementation, the server establishes a corresponding record (e.g., a log) for each generated key information. The record may include the time of key information generation, distribution status, usage frequency, vehicle device response status, etc., and is used for security auditing and risk control backtracking.

[0095] In one possible implementation, when generating key information based on the encryption key, the encryption key also supports algorithm switching compatibility, that is, the encryption key can support switching strategies such as the Chinese national cryptographic algorithm SM2 / SM4 and the international standard RSA / AES, so as to meet the encryption rules of different regions.

[0096] Furthermore, when generating key information based on the encryption key, a dynamic salt value can be generated by injecting a dynamic salt value in conjunction with a TBOX random factor. This allows for modification of the generated key information, preventing static replay attacks. In addition, the generated key information also satisfies a structured signature mechanism, meaning that a structured hash signature is appended after the key information is finally formatted to prevent tampering and ensure more reliable verification.

[0097] In this embodiment, when generating key information based on user registration and login information, the identifier of the vehicle-mounted device can be encrypted using an encryption key to generate ciphertext. Then, based on the target field and timestamp extracted from the ciphertext, key information is generated. Thus, by including information related to the identifier of the vehicle-mounted device in the key information, the user's key information can be associated with the identifier of the vehicle-mounted device, thereby improving key security.

[0098] S202. Perform security authentication on the key information.

[0099] Among them, security authentication is used to verify whether the user has the authority to debug the in-vehicle equipment.

[0100] In some embodiments, in a debugging method provided by this application, step S202 may specifically include: encrypting the identifier of the vehicle device based on a pre-written encryption key in the vehicle device to obtain ciphertext, wherein the encryption key is written during the production testing of the vehicle device and is in a read-only state in the vehicle device; and performing security authentication on the key information based on the target field in the ciphertext.

[0101] In one possible implementation, after receiving login information entered by the user, the on-board device immediately initiates the authentication submodule, executing a complete authentication process equivalent to that of a server. First, the on-board device extracts its identifier (e.g., its serial number) from a security chip or electrically erasable programmable read-only memory (EEPROM), and then encrypts this identifier using a hardware encryption engine (supporting AES / SM4 / ARM Trust Zone, etc.) to generate a locally ciphertext with a consistent structure.

[0102] Subsequently, the system extracts the target field specified in the ciphertext (e.g., the first byte to the fourth byte), compares it with the content entered by the user (i.e., the key information in the login information) according to the preset cryptographic structure rules (encryption key), and performs security authentication on the key information.

[0103] Specifically, the comparison process may include multiple dimensions of verification, such as field format verification (e.g., whether the prefix is ​​SEC_), whether the timestamp is within the validity period, whether the content is consistent, and whether there are signature errors.

[0104] In one possible implementation, after successful key information security authentication, the system will activate the debugging interface corresponding to the user's permission level, load the matching instruction set, and allow the user to perform operations such as log collection, network diagnostics, and CAN bus monitoring. If key information security authentication fails, the reason for the failure and the timestamp can be recorded.

[0105] In one possible implementation, when the number of consecutive security authentication failures of key information exceeds a threshold (e.g., three consecutive authentication failures), the system will immediately freeze the debug port access and report to the TBOX central module, which will then report the abnormal security behavior to the server through the cloud channel, thereby enabling linkage between the vehicle-mounted device and the server.

[0106] In one possible implementation, after successful security authentication of the key information, the execution of debugging commands triggered by the user will also be written to the audit log system. This log includes authentication records, user identification (such as Bluetooth device, employee ID code, etc.), debugging commands and execution results, timestamps, and other information. It can be uniformly exported and encrypted and archived through a server or vehicle log tool.

[0107] For example, such as Figure 3 As shown, the server can obtain a first key based on the vehicle device's identifier and encryption key. The vehicle device can hash the root partition file to obtain an encryption key for writing to the vehicle device. Then, the vehicle device further combines the vehicle device's identifier and encryption key to obtain a second key. Furthermore, the vehicle device compares the first key obtained from the server with the second key obtained locally. If the comparison is successful, the login information authentication is completed, and memory is released. The encryption key used by the server to obtain the first key is the same as the encryption key used by the vehicle device to obtain the second key.

[0108] In this embodiment, an encryption key can be pre-written during the production and testing of the vehicle-mounted device. Therefore, when performing security authentication on the key information, the identifier of the vehicle-mounted device can be encrypted using the same encryption key as the generated key information to obtain ciphertext. The key information can then be authenticated based on the target field in the ciphertext. Thus, using the same encryption key for security authentication improves the accuracy of the authentication. Furthermore, by setting the encryption key to read-only mode in the vehicle-mounted device, attackers can be prevented from tampering with the encryption key, further enhancing the accuracy of the security authentication.

[0109] In some embodiments, in a debugging method provided by this application, step S202 may specifically include: sending key information to a server to perform security authentication on the key information through the server, wherein the server includes the same encryption key as the vehicle-mounted device; and receiving the security authentication result sent by the server.

[0110] In one possible implementation, the high latency issues associated with frequent communication can be avoided by pre-synchronizing a lightweight encryption algorithm (i.e., encryption key, such as AES-256) between the server and the in-vehicle device. Based on this, the in-vehicle device can also send the user-inputted key information to the server for secure authentication, and the server will then return the authentication result to the in-vehicle device.

[0111] In one possible implementation, during later product upgrades via Over-The-Air Technology (OTA) or system version upgrades, the vehicle-mounted equipment also needs to maintain consistency of the encryption algorithm parameters of the encryption key with the server.

[0112] The server includes the same encryption key as the in-vehicle device, indicating that the encryption algorithm parameters in the server are identical to those in the in-vehicle device. Specifically, the encryption algorithm parameters may include: encryption algorithm type (e.g., AES-256-CBC, SM4-CBC, etc.) and encryption mode, key length and symmetry verification rules (e.g., verification strategy for dynamically rotating keys), digest format of encrypted output and field parsing method, ciphertext processing rules (e.g., which fields to extract from the ciphertext, reverse encoding, dynamic salt concatenation, etc.), version identifier and authentication protocol header identifier (e.g., SEC_, SVC_, etc., used for protocol generation management).

[0113] In one possible implementation, the vehicle-mounted device needs to verify whether the configuration file of the current encryption key is consistent with the signature hash of the encryption key on the server side during each initialization. If there is a configuration drift, the authentication mechanism is paused and a request is made to resynchronize the parameter package to ensure that the authentication process is secure and consistent.

[0114] In this embodiment, the same encryption key as the vehicle-mounted device can be set on the server, thereby enabling secure authentication of the key information through the server. This leverages the server's powerful data processing capabilities to improve the efficiency of security authentication.

[0115] S203. If the key information passes security authentication, determine the target permission range for the user to debug the vehicle-mounted equipment based on the login information.

[0116] Different login information corresponds to different permission ranges, and the target permission range is determined based on any of the following: account information, the target role level of the user determined by the account information, and the instruction information determined in the key information.

[0117] In one possible implementation, after the key information has passed security authentication, further user permission and security auditing can be performed, thereby loading different permission configuration templates based on the current user's role level. Each template includes information such as: maximum number of executions, maximum command input rate, command whitelist and / or command blacklist, and whether sensitive commands require secondary authorization authentication.

[0118] The user's role level can be determined in any of the following ways: user's work badge identifies the user's role level, Bluetooth pairing determines the user's role level, or physical key determines the user's role level.

[0119] In some embodiments, in a debugging method provided by this application, the step S203 above, "determining the target permission range for the user to debug the vehicle-mounted device based on login information," may specifically include: determining the permission range corresponding to the user's target role level based on account information; and determining the target permission range within the permission range corresponding to the user's target role level based on key information.

[0120] Different role levels correspond to different permission ranges. The target role level is any one of the following: equipment debugging personnel, equipment maintenance personnel, equipment development personnel. Different users with the same role level have different levels, and users with different levels have different target permission ranges.

[0121] In other words, for multiple users belonging to the same role level, the level of each user (e.g., level 1, level 2, level 3, etc.) can be determined based on user information. Different user levels will have different target permission ranges within the permission scope corresponding to that role level. The higher the user level (level 1 is the lowest, level 3 is the highest), the larger the corresponding target permission range.

[0122] In one possible implementation, user authorization can be based on the granularity of key information. This allows for the configuration of multiple key information sets for the same in-vehicle device, enabling different key sets to be used for different scenarios such as debugging, maintenance, and development.

[0123] That is, when a user performs security authentication using different key information, the vehicle-mounted device can determine the user's corresponding target permission range when the security authentication is passed.

[0124] In one possible implementation, once the key information has been securely authenticated, the vehicle-mounted device can open the debugging interface according to the principle of least privilege, with the target permission scope being the restriction of the user's debugging permissions.

[0125] In one possible implementation, the permission scope corresponding to different role levels can be predetermined. For example, when the role level is "device debugging personnel," the permission scope required for debugging the equipment can be determined; when the role level is "device maintenance personnel," the permission scope required for maintaining the equipment can be determined; and when the role level is "device development personnel," the permission scope required for developing the equipment can be determined.

[0126] Thus, the account information can include indication information for indicating the user's role level, and the user's target role level can be determined based on the indication information for indicating the role level determined from the account information.

[0127] In one possible implementation, for users belonging to the same role level (i.e., account information), different user levels can be set for different users corresponding to the same role level. This allows for further restriction of the target permission range for users at different user levels within the permission scope corresponding to that role level.

[0128] For example, for a user with a specific role level (such as a device debugging personnel), user levels such as beginner, intermediate, and advanced users can be further defined. Furthermore, within the permission scope corresponding to a specific role level, the permission scope corresponding to different user levels is determined. Specifically, the permission scope of a beginner user is less than that of an intermediate user, and the permission scope of an intermediate user is less than that of an advanced user.

[0129] Thus, the account information can also include indication information for the user's level. Based on the indication information for the user's level determined from the account information, the target permission range corresponding to the user can be further determined within the permission range corresponding to the user's target role level.

[0130] In this embodiment, the application can directly determine the permission range corresponding to the user's target role level based on the account information in the user's login information, and then determine the target permission range within the permission range corresponding to the user's target role level based on the key information. Thus, by using the user's target role level indicated by the account information, the permission range corresponding to that target role level can be determined first. Then, based on the user's key information, the user's target permission range within the determined permission range corresponding to the target role level can be further determined. Therefore, by setting different permission ranges corresponding to different role levels, the user's permission range can be determined more accurately step by step. This avoids users exceeding their authority when debugging in-vehicle equipment, which could affect the security of the in-vehicle equipment.

[0131] In some embodiments, in a debugging method provided by this application, the step S203 above, "determining the target permission range for the user to debug the vehicle-mounted device based on login information", may specifically include: determining the target permission range based on account information, where different account information corresponds to different permission ranges.

[0132] In one possible implementation, the permission scope corresponding to different account information can be predetermined. That is, the permission scope of the account information in the login information can be set when the user registers and logs in. Furthermore, a table mapping account information to permission scopes can be constructed to store the different permission scopes corresponding to different account information.

[0133] Thus, after determining the account information in the login information entered by the user, the target permission scope corresponding to the account information can be determined based on the correspondence table between account information and permission scope.

[0134] In this embodiment, the application can directly determine the target permission range of a user based on the account information in the user's login information. Thus, by setting permission ranges corresponding to different user account information, the permission range of each user can be accurately determined. This allows for precise restriction of user debugging permissions when a user is debugging in-vehicle equipment, preventing users from exceeding their permissions and affecting the security of the in-vehicle equipment.

[0135] In some embodiments, in a debugging method provided by this application, the step S203 above, "determining the target permission range for the user to debug the vehicle-mounted device based on login information", may specifically include: determining the target permission range based on indication information determined from key information, the indication information being associated with the user, and the indication information being used to indicate the target permission range.

[0136] In one possible implementation, instruction information can be added to the registered key information during user registration and login. This instruction information indicates the user's target permission range. Furthermore, a key information-permission range mapping table can be constructed to store the different permission ranges for different users.

[0137] Thus, after determining the key information in the login information entered by the user, the target permission range corresponding to the key information can be determined based on the key information and permission range mapping table.

[0138] In this embodiment, the target permission range of a user can be directly determined based on the indication information in the user's key information. Thus, by adding user-associated indication information to the key information during key setting to indicate the user's permission range for debugging the in-vehicle device, the user's permission range can be accurately determined when the user inputs the key information. This allows for precise restriction of the user's debugging permissions when debugging the in-vehicle device, preventing unauthorized debugging that could compromise the device's security.

[0139] S204. Respond to or reject the debugging command within the target's permission scope.

[0140] Based on this, when a user issues a debugging command to the vehicle-mounted device, the device can determine whether to respond to or reject the command based on the defined target permission range, thereby preventing the user from exceeding their authority to debug the device.

[0141] In this embodiment, in the scenario of debugging in-vehicle equipment, the application can perform secure authentication on the key information in the user's login information. If the user is verified to have debugging permissions for the in-vehicle equipment, the application can further determine the user's target permission range for debugging the in-vehicle equipment based on the login information. The in-vehicle equipment will then respond to or reject the user's debugging command within the user's corresponding target permission range. Thus, when different users debug the in-vehicle equipment using different login information, the permission range for each user can be determined, allowing users to debug the in-vehicle equipment only within their permitted permission range. This prevents users from exceeding their permissions and ensures the security of user authentication for debugging in-vehicle equipment.

[0142] In some embodiments, the target permission scope is used to indicate the maximum number of executions; such as Figure 4 As shown, in a debugging method provided in this application embodiment, step S204 may specifically include S401-S403:

[0143] S401. In response to receiving a new debugging instruction, determine the number of times the debugging instruction has been executed within the historical time period prior to the current moment.

[0144] In one possible implementation, when determining the target scope of user permissions for debugging the in-vehicle equipment, the user's permissions can be restricted by determining the maximum number of times the in-vehicle equipment can respond to user-inputted debugging commands within a certain time period (preset duration). When the number of times the user responds to user-inputted debugging commands within a certain time period reaches the maximum number of executions, it indicates that the user has exceeded their debugging permissions for the in-vehicle equipment, and therefore further debugging of the in-vehicle equipment by the user needs to be restricted.

[0145] In one possible implementation, the duration of user-initiated debugging of the in-vehicle device can be determined based on a preset duration and the time when the user begins debugging (e.g., the time when the user's login information is verified through security). This allows for the determination of the number of times debugging commands have been executed by the in-vehicle device during the historical time period between the time the user began debugging and the current moment.

[0146] S402. If the number of executions is less than the maximum number of executions, respond to the new debugging command.

[0147] S403. If the number of executions is greater than or equal to the maximum number of executions, reject new debugging instructions.

[0148] In this embodiment, the application can constrain a user's debugging permissions for in-vehicle devices by setting a maximum number of executions. Upon receiving a new debugging command, the application assesses the command to determine the number of debugging commands executed within a historical time period prior to the current moment. A new debugging command is only responded to if the number of previously executed commands is less than the set maximum; otherwise, the new command is rejected if the number of previously executed commands is greater than or equal to the set maximum. Thus, by setting a maximum number of executions to limit the number of times a user can debug in-vehicle devices within a certain time period, frequent debugging by the user can be avoided, which could impact the performance or security of the in-vehicle devices.

[0149] In some embodiments, the target permission range is used to indicate the maximum instruction input rate; such as Figure 5 As shown, in a debugging method provided in this application embodiment, step S204 may specifically include S501-S503:

[0150] S501, in response to receiving a new debugging instruction, determines the instruction input rate within the historical time period prior to the current moment.

[0151] In one possible implementation, when determining the target access range for user debugging of the in-vehicle equipment, user access can be restricted by setting a maximum input rate for debugging commands. When the user inputs debugging commands at the maximum input rate, it indicates that the number of debugging commands input by the user is too fast, and therefore it is necessary to limit the input rate of debugging commands into the in-vehicle equipment.

[0152] This is because when the user inputs debugging commands too quickly, it exceeds the command response capacity of the onboard equipment. The onboard equipment cannot respond to the user's debugging commands in time, resulting in abnormal command response, equipment lag, or missed debugging commands. Therefore, by setting a maximum command input rate, the rate at which the user inputs debugging commands to the onboard equipment can be limited.

[0153] S502. When the instruction input rate is less than or equal to the maximum instruction input rate, respond to new debugging instructions.

[0154] S503: If the instruction input rate is greater than the maximum instruction input rate, reject new debugging instructions.

[0155] Thus, when the user's input rate for debugging commands exceeds the maximum input rate, a prompt message can be displayed to remind the user to reject the new debugging command, allowing the user to retry the command at a later time.

[0156] In this embodiment, the application can constrain a user's debugging permissions for the in-vehicle device by setting a maximum command input rate. Upon receiving a new debugging command, the application judges the command input rate of the user within a historical time period prior to the current moment. The new debugging command is only responded to if its input rate is less than or equal to the set maximum input rate; otherwise, it is rejected. Thus, by setting a maximum command input rate to constrain the user's debugging rate of the in-vehicle device within a certain time period, it can prevent the user from rapidly issuing multiple debugging commands to the in-vehicle device, thereby avoiding abnormal situations caused by the in-vehicle device being unable to process a large number of debugging commands in a short period.

[0157] In some embodiments, the target permission scope is used to indicate a command whitelist and / or a command blacklist; such as Figure 6 As shown, in a debugging method provided in this application embodiment, step S204 may specifically include S601-S603:

[0158] S601. In response to obtaining a new debugging instruction, check whether the new debugging instruction is in the instruction blacklist and / or instruction whitelist.

[0159] In one possible implementation, a whitelist and / or blacklist of commands can be pre-built to determine the permissions of different users for all debugging commands involved in the debugging process of the in-vehicle device. That is, for the same debugging command, when different users enter the same debugging command into the in-vehicle device, due to the different user permission ranges, the in-vehicle device can respond to the same debugging command entered by one user, while rejecting the same debugging command entered by another user.

[0160] For example, for all modulation commands, a command whitelist and / or command blacklist can be set for the user. This divides all modulation commands into two parts based on the user's target permission range: one part serves as the command whitelist, and the other as the command blacklist. Therefore, when a user inputs a debugging command (i.e., a new debugging command), it can be determined which part of the command whitelist and / or command blacklist the command belongs to, thus determining whether the user has the debugging permissions corresponding to that specific debugging command.

[0161] S602. If a new debugging command is in the command blacklist, reject the new debugging command.

[0162] S603. If a new debug command is in the command whitelist, respond to the new debug command.

[0163] In this embodiment, the application can restrict user debugging permissions for in-vehicle equipment by setting a command whitelist and / or a command blacklist. Upon receiving a new debugging command, the application judges whether the new command is in the command blacklist and / or command whitelist. Debugging commands in the command blacklist are rejected, while those in the command whitelist are responded to. Thus, by determining whether a new debugging command is in the command blacklist and / or command whitelist, the legitimacy of obtaining a new debugging command is determined, thereby improving the security of the debugging process for in-vehicle equipment.

[0164] In some embodiments, the target permission scope is used to indicate secondary authentication during debugging; such as Figure 7 As shown, in a debugging method provided in this application embodiment, step S204 may specifically include S701-S703:

[0165] S701: In response to receiving a new debugging command, obtain the first authentication information input by the user.

[0166] The first authentication information is used for secondary authentication of the user.

[0167] In one possible implementation, for certain debugging commands that are of high importance (greater than the preset importance level) or high sensitivity (greater than the preset sensitivity level), after the user inputs such a debugging command (i.e., a new debugging command), the vehicle-mounted device can further prompt the user whether such a debugging command needs to be executed. Only when the user further confirms that such a debugging command needs to be executed (i.e., to authenticate the first authentication information input by the user), will the device respond to such a debugging command.

[0168] The terms "high importance" and "high sensitivity" can be understood as meaning that these debugging commands will cause significant changes in the operation of the on-board equipment.

[0169] For example, if it is determined that a new debugging command is of high importance or high sensitivity, the user can be prompted to further authenticate their initial authentication information. The user then inputs further initial authentication information so that the on-board device can authenticate this information.

[0170] In one possible implementation, the first authentication information can be any of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, gesture pattern, etc.

[0171] S702, if the first authentication information is successfully authenticated, respond to the new debugging command.

[0172] S703: If the first authentication information fails to pass authentication, reject the new debugging command.

[0173] In this embodiment, the accuracy of user debugging of in-vehicle equipment can be limited by setting a secondary authentication restriction during debugging. Upon receiving a new debugging command, secondary authentication is performed on the user to verify the first authentication information entered by the user. The new debugging command is only responded to if the first authentication information is successfully authenticated; otherwise, the new debugging command is rejected. Thus, by setting a secondary authentication restriction to determine the legitimacy of the user's debugging command, the security of the debugging process for in-vehicle equipment can be further improved.

[0174] In some embodiments, the debugging method provided in this application may further include: uploading the identifier of the vehicle device, the firmware version information of the vehicle device, and the version information of the encryption key to a server to establish a target mapping relationship on the server. The target mapping relationship is used to indicate the correspondence between the vehicle device and the encryption key, and the target mapping relationship is used by the server to perform security authentication on the key information.

[0175] In this embodiment of the application, the application can establish a target mapping relationship on the server based on the identifier of the vehicle device, the firmware version information of the vehicle device, and the version information of the encryption key, so as to determine the correspondence between the vehicle device and the encryption key. This allows the server to perform accurate security authentication of the key information based on the information corresponding to the vehicle device when performing security authentication of the key information.

[0176] In some embodiments, such as Figure 8 As shown, the debugging method provided in this application embodiment may further include S801-S803:

[0177] S801. Obtain the debugging logs generated during the user's debugging of the vehicle-mounted equipment.

[0178] In one possible implementation, during the user's debugging of the in-vehicle equipment, the debugging process (i.e., the input of debugging commands, the response of the in-vehicle equipment to the debugging commands, etc.) can be recorded in real time, thereby generating corresponding debugging logs.

[0179] That is, all debugging activities of users on vehicle-mounted equipment will be audited in their entirety, and the resulting debugging logs will be written to a local, tamper-proof storage partition and automatically encrypted and uploaded to the server's log analysis system.

[0180] S802. Detect the debug log and, if an abnormal operation is detected, obtain the second authentication information entered by the user.

[0181] Abnormal operations include at least one of the following: debugging failure frequency is greater than the preset frequency, instructions exceed the target permission range, and instructions have abnormal structure. The second authentication information includes at least one of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, and gesture pattern. The second authentication information is used to perform secondary authentication on the user.

[0182] In one possible implementation, an Artificial Intelligence (AI) abnormal behavior detection model can be deployed on the server to monitor in real time for abnormal behavior patterns in the debug logs, such as a sudden increase in the frequency of debug failures, continuous unauthorized attempts in instructions, and abnormal command structures.

[0183] In one possible implementation, if an abnormal operation is detected from the debug log, the on-board device can automatically enable a secondary authentication mechanism to authenticate the user's second authentication information.

[0184] In one possible implementation, the second authentication information can be any of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, gesture pattern, etc.

[0185] For example, if an abnormal operation is detected from the debug log, the user can be prompted to further authenticate their second authentication information. The user then inputs further second authentication information, which the on-board unit then authenticates.

[0186] S803. Authenticate the second authentication information. If the second authentication information is successfully authenticated, continue to respond to or reject debugging commands within the target permission scope.

[0187] In one possible implementation, the user is only allowed to continue debugging the in-vehicle device if the second authentication information entered by the user is successfully authenticated. If the second authentication information fails to authenticate, the user is denied further debugging of the in-vehicle device.

[0188] In this embodiment, the application can further detect the debugging logs to perform secondary authentication on the user if the debugging failure frequency exceeds a preset frequency, the command exceeds the target permission range, or the command structure is abnormal. This further verifies the second authentication information entered by the user. Only if the second authentication information is successfully authenticated is the user allowed to continue debugging the in-vehicle device, and continue to respond to or reject debugging commands within the target permission range. This prevents users from exceeding their permissions to debug the in-vehicle device, or attackers from accessing the in-vehicle device, thereby improving the security of the in-vehicle device.

[0189] In this embodiment, to enhance system robustness and ensure availability and security under abnormal boundary conditions, a multi-dimensional redundancy mechanism is designed. A hardware fault monitoring module scans the chip serial number status in real time; if a read error occurs, a specific error code ERR_NO_HWID is returned, and all authentication modules are forcibly disabled. A dual-instance loading strategy is used in the encryption module; if the main algorithm module fails to load, the system automatically switches to the backup engine (e.g., fallback AESimplementation). Furthermore, in the event of a network outage or the vehicle-mounted device being offline, the device can use a 24-hour cached password for temporary authentication. And after each power outage and restart of the vehicle-mounted device, authentication initialization is re-executed, and the previous authentication session is verified to have not been illegally reused.

[0190] In one possible implementation, the in-vehicle device also supports progressively deployed multi-level security enhancement modules, including but not limited to: using Bluetooth physical key binding, requiring users to activate the Bluetooth device paired with the device before authentication and use its provided dynamic token to complete the final verification; and using biometric authentication modules such as facial recognition information, fingerprint recognition information, and iris recognition information to directly form a two-level cross-binding with the authentication password.

[0191] In one possible implementation, during the response to user-inputted debugging commands, the system can also support structural signing of the commands for encrypted storage. This automatically generates an encrypted archive record after the debugging command is executed. Consequently, during subsequent review and auditing of the debugging commands, the structural signature can be used for secure verification. This prevents attackers from obtaining the debugging commands and using them to attack the vehicle's equipment.

[0192] In one possible implementation, when the on-board device receives a debugging command input by the user, it can further determine the location information and time at which the debugging command was received. Based on this location information and time, the debugging command can then be further verified to determine whether to respond to it.

[0193] That is, by setting a designated area (such as a service station) that allows debugging of the vehicle-mounted equipment, the system can determine whether to respond to the received debugging command by judging whether the location information of the vehicle-mounted equipment receiving the debugging command belongs to the designated area; and by setting a designated time window that allows debugging of the vehicle-mounted equipment (such as disabling it at night and allowing debugging from 8:00 to 22:00 every day), the system can determine whether to respond to the received debugging command by judging whether the time when the vehicle-mounted equipment receives the debugging command belongs to the designated time window.

[0194] The authentication scheme proposed in this application constructs a five-layer security protection system consisting of hardware security, algorithm security, operational behavior control, log auditing and tracing, and server-linked response, forming a deeply layered and collaborative debugging access control mechanism. This system not only effectively meets the current needs of intelligent cockpits and autonomous driving systems for fine-grained control of debugging interface permissions, but also has good scalability, adaptable to future application expansions in intelligent edge computing devices, industrial gateway nodes, and unmanned vehicle debugging systems.

[0195] Meanwhile, each security module is customizable and configurable, allowing enterprises to deploy it as needed based on actual business requirements and scenario risk levels, covering everything from lightweight development and verification scenarios to high-level secure production environments. The system supports remote dynamic configuration distribution, module activation, and policy switching via OTA, building remote access control and security authentication capabilities throughout the entire device lifecycle.

[0196] Based on this, this application, through the comprehensive construction and engineering implementation of this authentication system, effectively fills the gaps in traditional ADB debugging regarding device uniqueness authentication and dynamic access control. It propels the debugging system from the traditional paradigm of "static password + weak verification" to a dynamic and scalable new authentication model of "physical binding + hierarchical permissions + automatic circuit breaking," which is particularly suitable for the increasingly complex intelligent connected vehicles and their aftermarket maintenance ecosystem, possessing significant industrial application value and promising prospects for widespread adoption. This achieves hardware-bound one-device-one-key authentication, completely eliminating the problems of traditional password copying and cross-device reuse; furthermore, local password generation has low computational load, with a single transaction time controlled within 10ms, adapting to the resource constraints of in-vehicle embedded platforms; the verification mechanism supports exception handling and retry control to prevent system cracking; access control is fine-grained, with debugging operations strictly limited to the authorized instruction set; it supports multi-factor authentication, biometric fusion, physical key and other mechanisms for expansion, possessing strong scalability and security redundancy capabilities.

[0197] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the debugging device or electronic device includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0198] This application embodiment can, based on the above method, exemplarily divide a debugging device or electronic device into functional modules. For example, the debugging device or electronic device may include functional modules corresponding to each functional division, or two or more functions may be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0199] Figure 9 This is a block diagram illustrating a debugging apparatus according to an exemplary embodiment. (Refer to...) Figure 9 The debugging device 900 includes: an acquisition module 901, an authentication module 902, a determination module 903, a processing module 904, and a sending module 905.

[0200] The acquisition module 901 is used to acquire login information input by the user, including account information and key information; the authentication module 902 is used to perform security authentication on the key information, which verifies whether the user has the right to debug the vehicle-mounted device; the determination module 903 is used to determine the target permission range for the user to debug the vehicle-mounted device based on the login information if the key information passes security authentication. Different login information corresponds to different permission ranges, and the target permission range is determined based on any of the following: account information, the user's target role level determined by the account information, or the indication information determined in the key information; the processing module 904 is used to respond to or reject the debugging command within the target permission range.

[0201] In one possible implementation, the target permission range is used to indicate the maximum number of executions; the processing module 904 is specifically used to determine the number of times the debugging instruction has been executed in the historical time period before the current moment in response to obtaining a new debugging instruction; the processing module 904 is specifically used to respond to the new debugging instruction if the number of executions is less than the maximum number of executions; the processing module 904 is specifically used to reject the new debugging instruction if the number of executions is greater than or equal to the maximum number of executions.

[0202] In one possible implementation, the target permission range is used to indicate the maximum instruction input rate; the processing module 904 is specifically used to determine the instruction input rate in the historical time period before the current moment in response to obtaining a new debugging instruction; the processing module 904 is specifically used to respond to the new debugging instruction when the instruction input rate is less than or equal to the maximum instruction input rate; the processing module 904 is specifically used to reject the new debugging instruction when the instruction input rate is greater than the maximum instruction input rate.

[0203] In one possible implementation, the target permission scope is used to indicate the instruction whitelist and / or instruction blacklist; the processing module 904 is specifically used to detect whether the new debugging instruction is in the instruction blacklist and / or instruction whitelist in response to the acquisition of a new debugging instruction; the processing module 904 is specifically used to reject the new debugging instruction if the new debugging instruction is in the instruction blacklist; the processing module 904 is specifically used to respond to the new debugging instruction if the new debugging instruction is in the instruction whitelist.

[0204] In one possible implementation, the target permission range is used to indicate secondary permission authentication during debugging; the processing module 904 is specifically used to obtain the first authentication information input by the user in response to obtaining a new debugging instruction; the processing module 904 is specifically used to respond to the new debugging instruction if the first authentication information is authenticated; the processing module 904 is specifically used to reject the new debugging instruction if the first authentication information is not authenticated.

[0205] In one possible implementation, the determining module 903 is specifically used to determine the permission range corresponding to the user's target role level based on account information. Different role levels correspond to different permission ranges. The target role level is any one of the following: debugging equipment personnel, maintenance equipment personnel, and development equipment personnel. Different users corresponding to the same role level have different levels, and users at different levels have different determined target permission ranges. The determining module 903 is specifically used to determine the target permission range within the permission range corresponding to the user's target role level based on key information.

[0206] In one possible implementation, the determining module 903 is specifically used to determine the target permission range based on account information, with different account information corresponding to different permission ranges.

[0207] In one possible implementation, the determining module 903 is specifically used to determine the target permission range based on indication information determined from the key information, the indication information being associated with a user and used to indicate the target permission range.

[0208] In one possible implementation, the key information is generated based on the identifier of the vehicle device, which includes at least one of the following: a unique identifier (UID), an electronic control unit (ECU) serial number, and a board support package (BSP) unique code.

[0209] In one possible implementation, the processing module 904 is further configured to encrypt the identifier of the vehicle-mounted device based on the encryption key to generate ciphertext when the user registers and logs in; the processing module 904 is further configured to extract the target field from the ciphertext and generate key information based on the target field and the timestamp, wherein the timestamp is used to limit the validity period of the key information.

[0210] In one possible implementation, the authentication module 902 is specifically used to encrypt the identifier of the vehicle-mounted device based on the encryption key pre-written in the vehicle-mounted device to obtain ciphertext. The encryption key is written during the production and testing of the vehicle-mounted device and is in a read-only state in the vehicle-mounted device. The authentication module 902 is specifically used to perform security authentication on the key information based on the target field in the ciphertext.

[0211] In one possible implementation, the authentication module 902 is specifically used to send key information to the server for secure authentication of the key information by the server, the server including the same encryption key as the vehicle-mounted device; the authentication module 902 is specifically used to receive the secure authentication result sent by the server.

[0212] In one possible implementation, the sending module 905 is used to upload the identifier of the vehicle device, the firmware version information of the vehicle device, and the version information of the encryption key to the server, so as to establish a target mapping relationship on the server. The target mapping relationship is used to indicate the correspondence between the vehicle device and the encryption key, and the target mapping relationship is used by the server to perform security authentication of the key information.

[0213] In one possible implementation, the acquisition module 901 is further configured to acquire debugging logs generated during the user's debugging of the vehicle-mounted device; the processing module 904 is further configured to detect the debugging logs; the acquisition module 901 is further configured to acquire second authentication information input by the user when an abnormal operation is detected, the abnormal operation including at least one of the following: the debugging failure frequency is greater than a preset frequency, the instruction exceeds the target permission range, or the instruction structure is abnormal, and the second authentication information includes at least one of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, or gesture pattern; the processing module 904 is further configured to authenticate the second authentication information; the processing module 904 is further configured to continue to respond to or reject debugging instructions within the target permission range if the second authentication information is successfully authenticated.

[0214] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0215] Figure 10 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Figure 10 As shown, the electronic device 1000 includes, but is not limited to, a processor 1001 and a memory 1002.

[0216] The aforementioned memory 1002 is used to store the executable instructions of the aforementioned processor 1001. It is understood that the aforementioned processor 1001 is configured to execute instructions to implement the debugging method in the above embodiments.

[0217] It should be noted that those skilled in the art will understand that Figure 10 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 10 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0218] The processor 1001 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 1002, and by calling data stored in the memory 1002, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. The processor 1001 may include one or more processing units. Optionally, the processor 1001 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1001.

[0219] The memory 1002 can be used to store software programs and various data. The memory 1002 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a processing module, a storage module, etc.), etc. Furthermore, the memory 1002 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0220] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1002 including instructions, which can be executed by a processor 1001 of an electronic device 1000 to implement the debugging method in the above embodiments.

[0221] In actual implementation, Figure 9 The functions of the acquisition module 901, authentication module 902, determination module 903, processing module 904, and sending module 905 can all be provided by... Figure 10 The processor 1001 calls the computer program stored in the memory 1002 to implement the process. The specific execution process can be found in the description of the debugging method section of the previous embodiment, and will not be repeated here.

[0222] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0223] In an exemplary embodiment, this application also provides a computer program product including one or more instructions, which can be executed by the processor 1001 of the electronic device 1000 to complete the debugging method in the above embodiments.

[0224] It should be noted that when one or more instructions in the computer-readable storage medium or computer program product are executed by the processor of the electronic device, they implement the various processes of the above-described debugging method embodiments and achieve the same technical effect as the above-described debugging method. To avoid repetition, they will not be described again here.

[0225] Figure 11 This is a schematic diagram illustrating the structure of a computer system for an electronic device according to an exemplary embodiment. It should be noted that... Figure 11 The computer system of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0226] like Figure 11 As shown, the computer system includes a Central Processing Unit (CPU), which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) or loaded from storage into Random Access Memory (RAM), such as executing the methods described in the above embodiments. The RAM also stores various programs and data required for system operation. The CPU, ROM, and RAM are interconnected via a bus. Input / Output (I / O) interfaces are also connected to the bus. The I / O interfaces are used to implement functions such as data input, output, communication, and storage; the storage function can be specifically implemented through removable media.

[0227] The following components are connected to the I / O interface: input sections including keyboards, mice, etc.; output sections including cathode ray tubes (CRTs), liquid crystal displays (LCDs), and speakers; storage sections including hard drives; and communication sections including network interface cards such as LAN (Local Area Network) cards and modems. The communication sections perform communication processing via networks such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical discs, magneto-optical discs, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage section as required.

[0228] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication component, and / or installed from a removable medium. When the computer program is executed by a central processing unit (CPU), it performs various functions defined in the system of this application.

[0229] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0230] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0231] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0232] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0233] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0234] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0235] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A debugging method, characterized in that, The debugging method includes: Obtain login information input by the user. The login information includes account information and key information. The key information is generated based on the identifier of the vehicle device. The identifier of the vehicle device includes at least one of the following: unique identifier UID, electronic control unit (ECU) serial number, and board support package (BSP) unique code. Based on the encryption key pre-written in the vehicle device, the identifier of the vehicle device is encrypted to obtain ciphertext. The encryption key is written during the production and testing of the vehicle device and is in a read-only state in the vehicle device. The key information is securely authenticated based on the target field in the ciphertext. The security authentication is used to verify whether the user has the right to debug the vehicle-mounted device. If the key information passes the security authentication, the target permission range for the user to debug the vehicle equipment is determined based on the login information. Different login information corresponds to different permission ranges. The target permission range is determined based on any one of the following: the account information, the user's target role level determined by the account information, or the indication information determined in the key information. Respond to or reject debugging commands within the scope of the target permissions; In response to receiving a new debugging instruction, determine whether the new debugging instruction meets preset conditions; wherein, the preset conditions include an importance level higher than a preset importance level and a sensitivity level higher than a preset sensitivity level; If the new debugging instruction meets the preset conditions, the first authentication information input by the user is obtained; If the first authentication information is successfully authenticated, the new debugging instruction is responded to; if the first authentication information is not successfully authenticated, the new debugging instruction is rejected. And / or, after responding to a debugging instruction within the target permission scope, the debugging method further includes: Upon detecting an abnormal operation, the second authentication information input by the user is obtained; the abnormal operation includes at least one of the following: the debugging failure frequency is greater than a preset frequency, the instruction exceeds the target permission range, or the instruction structure is abnormal; Authenticate the second authentication information; If the second authentication information is successfully authenticated, continue to respond to or reject debugging commands within the scope of the target permissions.

2. The debugging method according to claim 1, characterized in that, The target permission range is used to indicate the maximum number of executions; The process of responding to or rejecting debugging commands within the target's permission scope includes: In response to receiving new debugging instructions, determine the number of times the debugging instructions have been executed within the historical time period prior to the current moment; If the number of executions is less than the maximum number of executions, respond to the new debugging instruction; If the number of executions is greater than or equal to the maximum number of executions, the new debugging instruction is rejected.

3. The debugging method according to claim 1, characterized in that, The target permission range is used to indicate the maximum instruction input rate; responding to or rejecting debugging instructions within the target permission range includes: In response to receiving new debugging instructions, determine the instruction input rate within the historical time period prior to the current moment; If the instruction input rate is less than or equal to the maximum instruction input rate, respond to the new debugging instruction; If the instruction input rate is greater than the maximum instruction input rate, the new debugging instruction is rejected.

4. The debugging method according to claim 1, characterized in that, The target permission range is used to indicate the instruction whitelist and / or instruction blacklist; the step of responding to or rejecting debugging instructions within the target permission range includes: In response to receiving a new debugging instruction, it is detected whether the new debugging instruction is in the instruction blacklist and / or the instruction whitelist; If the new debugging instruction is in the instruction blacklist, the new debugging instruction will be rejected. If the new debugging instruction is in the instruction whitelist, respond to the new debugging instruction.

5. The debugging method according to claim 1, characterized in that, The first authentication information includes: facial recognition information, fingerprint recognition information, iris recognition information, remote key, gesture pattern, etc.

6. The debugging method according to claim 1, characterized in that, The step of determining the target permission range for the user to debug the vehicle-mounted equipment based on the login information includes: Based on the account information, the user's target role level is determined to have a different permission range. Different role levels correspond to different permission ranges. The target role level is any one of the following: debugging equipment personnel, maintenance equipment personnel, or development equipment personnel. Different users with the same role level have different levels, and users with different levels have different target permission ranges. The target permission range is determined based on the key information within the permission range corresponding to the user's target role level.

7. The debugging method according to claim 1, characterized in that, The step of determining the target permission range for the user to debug the vehicle-mounted equipment based on the login information includes: The target permission range is determined based on the account information, with different account information corresponding to different permission ranges.

8. The debugging method according to claim 1, characterized in that, The step of determining the target permission range for the user to debug the vehicle-mounted equipment based on the login information includes: Based on the indication information determined from the key information, the target permission range is determined, the indication information is associated with the user, and the indication information is used to indicate the target permission range.

9. The debugging method according to any one of claims 1-8, characterized in that, The key information is generated in the following manner: When the user registers the login information, the identifier of the vehicle-mounted device is encrypted based on the encryption key to generate ciphertext; The target field is extracted from the ciphertext, and the key information is generated based on the target field and the timestamp, wherein the timestamp is used to limit the validity period of the key information.

10. The debugging method according to claim 1, characterized in that, The debugging method also includes: The key information is sent to the server so that the server can perform the security authentication on the key information. The server includes the same encryption key as the vehicle-mounted device. Receive the security authentication result sent by the server.

11. The debugging method according to claim 10, characterized in that, The debugging method also includes: The identifier of the vehicle-mounted device, the firmware version information of the vehicle-mounted device, and the version information of the encryption key are uploaded to the server to establish a target mapping relationship on the server. The target mapping relationship is used to indicate the correspondence between the vehicle-mounted device and the encryption key, and the target mapping relationship is used by the server to perform the security authentication of the key information.

12. The debugging method according to claim 1, characterized in that, The second authentication information includes at least one of the following: facial recognition information, fingerprint recognition information, iris recognition information, remote key, and gesture pattern. The second authentication information is used to perform secondary authentication on the user. The abnormal operation detection process includes: Obtain the debugging logs generated during the user's debugging of the vehicle-mounted device; The debug logs are checked to determine whether the abnormal operation occurred.

13. A debugging device, characterized in that, The debugging device includes: an acquisition module, an authentication module, a determination module, and a processing module; The acquisition module is used to acquire login information input by the user. The login information includes account information and key information. The key information is generated based on the identifier of the vehicle device. The identifier of the vehicle device includes at least one of the following: unique identifier UID, electronic control unit (ECU) serial number, and board support package (BSP) unique code. The authentication module is used to encrypt the identifier of the vehicle-mounted device based on the encryption key pre-written in the vehicle-mounted device to obtain ciphertext. The encryption key is written during the production and testing of the vehicle-mounted device and is in a read-only state in the vehicle-mounted device. The authentication module is also used to perform security authentication on the key information based on the target field in the ciphertext. The security authentication is used to verify whether the user has the right to debug the vehicle device. The determining module is used to determine the target permission range for the user to debug the vehicle-mounted device based on the login information when the key information passes the security authentication. Different login information corresponds to different permission ranges. The target permission range is determined based on any one of the following: the account information, the user's target role level determined by the account information, and the indication information determined in the key information. The processing module is used to respond to or reject debugging commands within the target's permission range; After responding to the debugging command within the target permission scope, the process also includes: In response to receiving a new debugging instruction, determine whether the new debugging instruction meets preset conditions; wherein, the preset conditions include an importance level higher than a preset importance level and a sensitivity level higher than a preset sensitivity level; If the new debugging instruction meets the preset conditions, the first authentication information input by the user is obtained; If the first authentication information is successfully authenticated, the new debugging instruction is responded to; if the first authentication information is not successfully authenticated, the new debugging instruction is rejected. And / or, after responding to the debugging command within the target permission scope, it further includes: Upon detecting an abnormal operation, the second authentication information input by the user is obtained; the abnormal operation includes at least one of the following: the debugging failure frequency is greater than a preset frequency, the instruction exceeds the target permission range, or the instruction structure is abnormal; Authenticate the second authentication information; If the second authentication information is successfully authenticated, continue to respond to or reject debugging commands within the scope of the target permissions.

14. An electronic device, characterized in that, include: A processor and a memory; wherein the memory is used to store one or more programs, the one or more programs including computer execution instructions, and when the electronic device is running, the processor executes the computer execution instructions stored in the memory, and the electronic device executes the debugging method according to any one of claims 1-12.

15. A vehicle, characterized in that, The vehicle includes the debugging device as described in claim 13.

Images