Data security protection method, device and equipment and storage medium

Abstract

The application discloses a data security protection method, comprising the following steps: if a request message is received, the request message is parsed to obtain a device ID and a service ID contained in the request message; a private level corresponding to the service ID is obtained, and it is judged whether the device ID matches the private level; if the device ID does not match the private level, the access of the request message is denied. The application further discloses a data security protection device, equipment and storage medium. The application classifies the private level of the diagnostic function in the vehicle ECU, realizes the limitation of the permission of the access request, ensures that the data of the vehicle ECU is not maliciously acquired and the function is not randomly controlled, avoids the data interference between different ECUs, and improves the safety of the vehicle.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a data security protection method, apparatus, device, and storage medium. Background Technology

[0002] ECU (Electronic Control Unit), also known as the vehicle's "computer," is a component in every vehicle. Each car is equipped with many ECUs, such as the engine ECU and transmission ECU, and their purpose is to control the vehicle's driving status and realize various vehicle functions.

[0003] Currently, the various ECUs installed in the same vehicle mainly determine the vehicle status and driver intentions through data acquisition from various sensors and data exchange via the vehicle bus, and simultaneously control the vehicle through actuators. However, because the various ECUs in the vehicle exchange data through the vehicle bus connection, any ECU can be accessed by other ECUs within the vehicle, ECUs from external vehicles, or external devices sending an access request via the vehicle bus. This access request can then be used to access the diagnostic functions of that ECU, thereby maliciously obtaining diagnostic data or arbitrarily controlling function execution, such as illegally stealing data information or illegally rewriting firmware parameters.

[0004] Therefore, it is necessary to propose a solution that can provide data security protection for the ECU in a vehicle, and prevent data leakage or functional abnormalities caused by easy access to the diagnostic functions of the ECU. Summary of the Invention

[0005] The main objective of this invention is to provide a data security protection method, device, equipment, and storage medium, which aims to prevent the diagnostic functions of the ECU from being easily accessed, avoid malicious data acquisition and arbitrary control of functions, thereby improving vehicle safety.

[0006] To achieve the above objectives, the present invention provides a data security protection method, which includes the following steps:

[0007] If a request message is received, the request message is parsed to obtain the device ID and service ID contained in the request message;

[0008] Obtain the privatization level corresponding to the service ID, and determine whether the device ID matches the privatization level;

[0009] If the device ID does not match the privatization level, the access to the request message is rejected.

[0010] Preferably, the step of determining the privatization level corresponding to the request message based on the service ID, and determining whether the device ID matches the privatization level, includes:

[0011] The privatization level is determined by querying a preset privatization level table based on the service ID, wherein the privatization level is a first level, a second level, or a third level;

[0012] The sender of the request message is determined based on the device ID, wherein the sender is an external device, an on-board ECU, or a target diagnostic function;

[0013] Based on the sending end and the privatization level, it is determined whether the device ID matches the privatization level.

[0014] Preferably, the step of determining whether the device ID matches the privatization level based on the sending end and the privatization level includes:

[0015] If the sending end is an external device, and the privatization level is level one or level two, then it is determined that the device ID does not match the privatization level; or,

[0016] If the sending end is an external device and the privatization level is level three, then the device ID is determined to match the privatization level; or,

[0017] If the sending end is an in-vehicle ECU and the privatization level is Level 1, then it is determined that the device ID does not match the privatization level; or,

[0018] If the sending end is an in-vehicle ECU, and the privatization level is level two or level three, then it is determined that the device ID matches the privatization level; or,

[0019] If the sending end is a target diagnostic function, and the privatization level is level one, level two, or level three, then it is determined that the device ID matches the privatization level.

[0020] Preferably, after the steps of obtaining the privatization level corresponding to the service ID and determining whether the device ID matches the privatization level, the method further includes:

[0021] If the device ID matches the privatization level, then the request message is determined to have access rights.

[0022] Preferably, after the step of determining that the request message has access rights if the device ID matches the privatization level, the method further includes:

[0023] Based on the service ID, determine the diagnostic data and / or diagnostic function corresponding to the request message, and return the diagnostic data and / or execute the diagnostic function.

[0024] Preferably, before the step of parsing the request message to obtain the device ID and service ID contained in the request message if a request message is received, the method further includes:

[0025] Pre-define the privatization level corresponding to each service ID and configure the privatization level table.

[0026] Preferably, the data security protection method further includes:

[0027] If an active wake-up command is received, it is determined that the active wake-up command has access rights, and the diagnostic data corresponding to the active wake-up command is returned and / or the diagnostic function corresponding to the active wake-up command is executed.

[0028] Furthermore, to achieve the above objectives, the present invention also provides a data security protection device, the data security protection device comprising:

[0029] The parsing module is used to parse the request message if a request message is received, and obtain the device ID and service ID contained in the request message;

[0030] The judgment module is used to obtain the privatization level corresponding to the service ID and determine whether the device ID matches the privatization level;

[0031] The determination module is used to reject the access of the request message if the device ID does not match the privatization level.

[0032] In addition, to achieve the above objectives, the present invention also provides a data security protection device, which includes: a memory, a processor, and a data security protection program stored in the memory and executable on the processor. When the data security protection program is executed by the processor, it implements the steps of the data security protection method described above.

[0033] In addition, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a data security protection program, which, when executed by a processor, implements the steps of the data security protection method described above.

[0034] The data security protection method proposed in this invention, upon receiving a request message, parses the request message to obtain the device ID and service ID contained in the request message; obtains the privatization level corresponding to the service ID, and determines whether the device ID matches the privatization level; if the device ID does not match the privatization level, the access of the request message is rejected. By classifying the privatization level of diagnostic functions in a vehicle ECU, access requests are restricted, thereby ensuring that the vehicle ECU data is not maliciously obtained and its functions are not arbitrarily controlled, avoiding data interference between different ECUs, and improving vehicle security. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of the structure of a data security protection device in the hardware operating environment involved in the embodiments of the present invention;

[0036] Figure 2 This is a flowchart illustrating the first embodiment of the data security protection method of the present invention;

[0037] Figure 3 This is a schematic diagram of a data security protection device according to an embodiment of the present invention.

[0038] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0039] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0040] like Figure 1 As shown, Figure 1 This is a schematic diagram of the structure of a data security protection device in the hardware operating environment involved in the embodiments of the present invention.

[0041] In this embodiment of the invention, the terminal can be a PC, or a mobile terminal device with display function such as a smartphone, tablet computer, or portable computer.

[0042] like Figure 1As shown, the data security protection device may include: a processor 1001, such as a CPU; a network interface 1004; a user interface 1003; a memory 1005; and a communication bus 1002. The communication bus 1002 is used to enable communication between these components. The user interface 1003 may include a display screen or an input unit such as a keyboard; optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface). The memory 1005 may be high-speed RAM or stable non-volatile memory, such as a disk storage device. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0043] Optionally, data security protection equipment may also include cameras, RF (Radio Frequency) circuits, sensors, audio circuits, WiFi modules, etc. Sensors such as light sensors, motion sensors, and other sensors will not be elaborated upon here.

[0044] Those skilled in the art will understand that Figure 1 The terminal structure shown does not constitute a limitation on data security protection equipment and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0045] like Figure 1 As shown, the memory 1005, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a data security protection program.

[0046] exist Figure 1 In the data security protection device shown, the network interface 1004 is mainly used to connect to the backend server and communicate with the backend server; the user interface 1003 is mainly used to connect to the client (user terminal) and communicate with the client; and the processor 1001 can be used to call the data security protection program stored in the memory 1005.

[0047] In this embodiment, the data security protection device includes: a memory 1005, a processor 1001, and a data security protection program stored in the memory 1005 and executable on the processor 1001. When the processor 1001 calls the data security protection program stored in the memory 1005, it executes the steps of the data security protection methods in the following embodiments.

[0048] This invention also provides a data security protection method, referring to... Figure 2 , Figure 2This is a flowchart illustrating the first embodiment of the data security protection method of the present invention.

[0049] In this embodiment, the method includes the following steps:

[0050] Step S101: If a request message is received, the request message is parsed to obtain the device ID and service ID contained in the request message;

[0051] It should be noted that with the development of technology, the electronic systems inside vehicles are becoming increasingly complex. They can generally be divided into multiple subsystems such as the body, chassis, powertrain, infotainment system, and driver assistance system. Each subsystem consists of multiple ECU electronic controller units. In addition, the various ECUs are generally connected by the vehicle's CAN bus to enable communication between them.

[0052] In this embodiment, when any ECU in the vehicle receives a request message, it can first parse the request message to obtain the device ID and service ID contained in the request message.

[0053] Specifically, due to the electrification of vehicles, the internal controls of vehicles are generally handled by various ECUs. When vehicle diagnostics are required, diagnostic functions can be accessed by sending messages to obtain diagnostic data or perform diagnostic functions, such as reading fault code information, reading sensor information, upgrading or flashing firmware, and performing component operation tests. The request message received by the ECU corresponds to the access request. When a request message is received, it can be parsed to obtain the device ID and service ID contained in the request message. The device ID is the unique identifier corresponding to the sender of the request message, and the service ID is the unique identifier corresponding to the service accessed by the request message.

[0054] Step S102: Obtain the privatization level corresponding to the service ID, and determine whether the device ID matches the privatization level;

[0055] In this embodiment, after obtaining the device ID and service ID contained in the request message, the privatization level corresponding to the service ID can be obtained, and a judgment can be made on whether the device ID matches the privatization level corresponding to the service ID. For example, the diagnostic functions supported by each ECU can be privatized in advance, a privatization level can be set for each diagnostic function, and a preset privatization level table can be formed by the privatization level of each diagnostic function and the corresponding service ID. This privatization level table is configured in the vehicle when it leaves the factory. The privatization level can be a first level, a second level, or a third level. After obtaining the device ID and service ID corresponding to the request message, the privatization level can be determined according to the service ID in the preset privatization level table. The system queries the privatization level table to determine the privatization level corresponding to the service ID. Then, it determines the sender of the request message based on the device ID. The sender of the request message can be an external device, an on-board ECU, or a target diagnostic function. External devices include external diagnostic devices or external ECUs, and on-board ECUs include other ECUs inside the vehicle. Finally, it determines whether the device ID matches the privatization level based on the sender and the privatization level. For example, external devices match level 3, on-board ECUs match levels 2 and 3, and target diagnostic functions match levels 1, 2, and 3. This allows the system to control the access permissions of the request message based on the results.

[0056] Optionally, if the privatization level is Level 1, it means that only the target diagnostic function or the ECU that executes the diagnostic function has access. When the ECU receives an active wake-up command instead of a request message, it is determined that the ECU is actively wake-up. In this case, the corresponding diagnostic data can be obtained or the corresponding diagnostic function can be executed directly according to the active wake-up command.

[0057] Step S103: If the device ID does not match the privatization level, then the access of the request message is rejected.

[0058] In this embodiment, after obtaining the privatization level corresponding to the service ID, it is necessary to determine whether the device ID matches the privatization level. If it is determined that the device ID does not match the privatization level, the access of the request message is rejected.

[0059] Specifically, the privatization level corresponding to the service ID contained in the request message is obtained, and it is determined whether the device ID contained in the request message matches the privatization level. If the device ID does not match the privatization level, access to the request message is denied. For example, if the privatization level corresponding to the service ID is the second level, and the sender corresponding to the device ID is an external device, it is determined that the device ID does not match the privatization level, and the external device does not have access to the diagnostic function and / or diagnostic data corresponding to the request message. An access denial response message is then sent to the external device.

[0060] In this embodiment, if a request message is received, it is parsed to obtain the device ID and service ID contained in the request message. Then, the privatization level corresponding to the service ID is obtained, and it is determined whether the device ID matches the privatization level. If the device ID does not match the privatization level, access to the request message is denied. By classifying the privatization level of diagnostic functions in the vehicle ECU, access permissions for access requests are restricted, thereby ensuring that the vehicle ECU data is not maliciously obtained and its functions are not arbitrarily controlled, avoiding data interference between different ECUs, and improving vehicle security.

[0061] Based on the first embodiment, a second embodiment of the data security protection method of the present invention is proposed. In this embodiment, step S102 includes:

[0062] Step S201: Based on the service ID, query a preset privatization level table to determine the privatization level, wherein the privatization level is a first level, a second level, or a third level;

[0063] Step S202: Determine the sender of the request message based on the device ID, wherein the sender is an external device, an on-board ECU, or a target diagnostic function;

[0064] Step S203: Determine whether the device ID matches the privatization level based on the sending end and the privatization level.

[0065] In this embodiment, after obtaining the device ID and service ID contained in the request message, the privatization level corresponding to the service ID can be determined by querying a preset privatization level table based on the service ID. The privatization level is either the first level, the second level, or the third level. Then, the sender of the request message is determined based on the device ID. The sender is an external device, an in-vehicle ECU, or a target diagnostic function. Thus, the device ID is judged to match the privatization level based on the sender of the request message and the privatization level corresponding to the service ID.

[0066] Specifically, the vehicle's electronic system is configured with a preset privatization level table. After obtaining the device ID and service ID contained in the request message, it can query the preset privatization level table based on the service ID to obtain the privatization level corresponding to the service ID, and determine whether the privatization level is the first level, the second level, or the third level. Then, based on the device ID, it can determine whether the sender of the request message is an external device, an on-board ECU, or a target diagnostic function. Finally, based on the sender and the privatization level, it can determine whether the device ID matches the privatization level.

[0067] Optionally, step S203 includes:

[0068] Step S301: If the sending end is an external device and the privatization level is level one or level two, then determine that the device ID does not match the privatization level; or,

[0069] Step S302: If the sending end is an external device and the privatization level is level three, then determine that the device ID matches the privatization level; or,

[0070] Step S303: If the sending end is an in-vehicle ECU and the privatization level is Level 1, then determine that the device ID does not match the privatization level; or,

[0071] Step S304: If the sending end is an in-vehicle ECU and the privatization level is level two or level three, then determine that the device ID matches the privatization level; or,

[0072] Step S305: If the sending end is a target diagnostic function and the privatization level is the first level, the second level, or the third level, then determine that the device ID matches the privatization level.

[0073] In this embodiment, the device ID is determined to match the privacy level based on the sending end of the request message and the privacy level corresponding to the service ID. If the sending end is an external device and the privacy level is level 1 or level 2, then the device ID is determined not to match the privacy level; or, if the sending end is an external device and the privacy level is level 3, then the device ID is determined to match the privacy level; or, if the sending end is an in-vehicle ECU and the privacy level is level 1, then the device ID is determined not to match the privacy level; or, if the sending end is an in-vehicle ECU and the privacy level is level 2 or level 3, then the device ID is determined to match the privacy level; or, if the sending end is a target diagnostic function and the privacy level is level 1, level 2, or level 3, then the device ID is determined to match the privacy level.

[0074] Specifically, each ECU in the vehicle can store a list of diagnostic functions, including the diagnostic functions it supports. For example, the engine ECU supports diagnostic functions such as fault code reading, signal data reading, configuration code writing, firmware flashing, and component self-learning matching. By pre-setting the privatization level of each diagnostic function in the list, the ECU can be configured with a preset privatization level table. For example, if fault code reading is set to level three, then almost all ECUs and external devices can access the fault code reading function; if signal data reading is set to level two, then only the vehicle's internal ECUs can access the signal data reading function; if configuration code writing is set to level one, then neither the vehicle's internal ECUs nor external devices can access the configuration code writing function, and only the target diagnostic function and the ECU with that function can actively execute it.

[0075] Optionally, the third level is generally used for non-confidential vehicle data or diagnostic functions that have little impact on the vehicle, with a level of privatization equal to that of the public; the second level is generally used for functions that require data exchange between various ECUs, with a level of privatization equal to that of the vehicle; and the first level is used for functions with the highest level of confidentiality that can only be executed by the ECU itself, with a level of privatization equal to that of the ECU.

[0076] In this embodiment, if the sending end is an external device and the privatization level is level one or two, then it is determined that the device ID does not match the privatization level; or, if the sending end is an external device and the privatization level is level three, then it is determined that the device ID matches the privatization level; or, if the sending end is an in-vehicle ECU and the privatization level is level one, then it is determined that the device ID does not match the privatization level; or, if the sending end is an in-vehicle ECU and the privatization level is level two or three, then it is determined that the device ID matches the privatization level; or, if the sending end is a target diagnostic function and the privatization level is level one, level two, or level three, then it is determined that the device ID matches the privatization level. This implements a hierarchical privatization level for diagnostic functions in the vehicle ECU, allowing subsequent restrictions on access requests based on the privatization level, improving the accuracy of data security protection and enhancing vehicle security.

[0077] In this embodiment, the privatization level is determined by querying a preset privatization level table based on the service ID, wherein the privatization level is a first level, a second level, or a third level. Then, the sender of the request message is determined based on the device ID, wherein the sender is an external device, an in-vehicle ECU, or a target diagnostic function. Finally, based on the sender and the privatization level, it is determined whether the device ID matches the privatization level. By classifying the privatization level of diagnostic functions in the vehicle ECU, the accuracy of permission judgment for access requests is improved, thereby better ensuring that subsequent vehicle ECU data is not maliciously obtained and functions are not arbitrarily controlled, thus improving vehicle security.

[0078] Based on the first embodiment, a third embodiment of the data security protection method of the present invention is proposed. In this embodiment, after step S102, the method further includes:

[0079] Step S401: If the device ID matches the privatization level, then it is determined that the request message has access permission.

[0080] In this embodiment, if the device ID in the request message matches the privatization level corresponding to the service ID, then the request message is determined to have access permissions. For example, the access permissions of the request message can be controlled through the privatization level of the diagnostic function. The privatization level can be level 1, level 2, or level 3. The sender of the request message is determined based on the device ID. This sender can be an external device, an in-vehicle ECU, or the target diagnostic function. When the sender is determined to be an external device based on the device ID, the privatization level corresponding to the service ID must be level 3 for the device ID to match the privatization level; otherwise, there is no match. When the sender is determined to be an in-vehicle ECU based on the device ID, the privatization level corresponding to the service ID must be level 2 or level 3 for the device ID to match the privatization level; otherwise, there is no match. When the sender is determined to be the target diagnostic function based on the device ID, the privatization level corresponding to the service ID can be level 1, level 2, or level 3 for the device ID to match the privatization level. When the device ID matches the privatization level, the request message is determined to have access permissions, allowing the corresponding diagnostic data to be returned or the corresponding diagnostic function to be executed subsequently based on the request message.

[0081] In this embodiment, if the device ID matches the privatization level, the request message is determined to have access permission. By classifying the privatization level of diagnostic functions in the vehicle ECU, the accuracy of permission determination for access requests is improved, and having access permission does not affect the execution of diagnostic functions, thus enhancing vehicle security.

[0082] Based on the third embodiment, a fourth embodiment of the data security protection method of the present invention is proposed. In this embodiment, after step S103, the method further includes:

[0083] Step S501: Based on the service ID, determine the diagnostic data and / or diagnostic function corresponding to the request message, and return the diagnostic data and / or execute the diagnostic function.

[0084] In this embodiment, after determining that the request message has access permissions, the diagnostic data and / or diagnostic function corresponding to the request message can be determined according to the service ID, and the diagnostic data and / or the diagnostic function can be returned and executed.

[0085] Specifically, the Service ID corresponds to the data and / or information required by the request message.

[0086] The required function is a unique identifier. When the request message has access rights, the diagnostic data and / or diagnostic function corresponding to the request message can be accurately determined based on the service ID. Then, the diagnostic data is returned through the response message, and / or the diagnostic function is executed.

[0087] In this embodiment, the diagnostic data and / or diagnostic function corresponding to the request message are determined based on the service ID, and the diagnostic data and / or the diagnostic function are returned and executed. When the request message has the necessary access permissions, data or functions can be accurately returned or executed, avoiding impact on vehicle operation while ensuring data security.

[0088] Based on the first embodiment, a fifth embodiment of the data security protection method of the present invention is proposed. In this embodiment, before step S101, the method further includes:

[0089] Step S601: Pre-set the privatization level corresponding to each service ID and configure the privatization level table.

[0090] In this embodiment, the vehicle's electronic system pre-sets the privatization level corresponding to each service ID.

[0091] It also configures a privatization level table. For example, when a vehicle leaves the factory, the list of diagnostic functions corresponding to each ECU is determined, and the privatization level of each diagnostic function is set. Then, a privatization level table is formed and configured in the vehicle's electronic system, so that the privatization level can be quickly found in the privatization level table according to the service ID.

[0092] Optionally, if the privatization level of each diagnostic function of the ECU needs to be updated, it can also be updated and upgraded through the diagnostic function list after leaving the factory.

[0093] In this embodiment, by pre-setting the privatization level corresponding to each service ID and configuring a privatization level table, access requests can be controlled by classifying the privatization level of the diagnostic functions in the vehicle ECU, thereby improving vehicle security.

[0094] Based on the above embodiments, a sixth embodiment of the data security protection method of the present invention is proposed. In this embodiment, the data security protection method further includes:

[0095] Step S701: If an active wake-up command is received, it is determined that the active wake-up command has access rights, and the diagnostic data corresponding to the active wake-up command is returned and / or the diagnostic function corresponding to the active wake-up command is executed.

[0096] In this embodiment, if the ECU receives an active wake-up command, it can determine that the active wake-up command 0 has access rights, and return the diagnostic data corresponding to the active wake-up command and / or execute the diagnostic function corresponding to the active wake-up command.

[0097] Specifically, the ECU's active wake-up command can be issued by the vehicle's driver or by the ECU itself to actively wake up the ECU. Therefore, the active wake-up command has access to first-level diagnostic data or diagnostic functions, as well as second- and third-level access to diagnostic data or diagnostic functions. When an active wake-up command is received, it can be directly determined that it has access rights, and the corresponding diagnostic data and / or the corresponding diagnostic function can be returned.

[0098] In this embodiment, if an active wake-up command is received, it is determined that the active wake-up command has access permissions, and the diagnostic data corresponding to the active wake-up command is returned and / or the diagnostic function corresponding to the active wake-up command is executed. This ensures that the data the ECU needs to acquire or the functions it needs to execute are not affected by the privatization level classification, improving the accuracy of data security protection.

[0099] Furthermore, embodiments of the present invention also propose a data security protection device, referring to... Figure 3 The data security protection device includes:

[0100] The parsing module 10 is used to parse the request message if a request message is received, and obtain the device ID and service ID contained in the request message;

[0101] The judgment module 20 is used to obtain the privatization level corresponding to the service ID and determine whether the device ID matches the privatization level;

[0102] The determination module 30 is used to reject the access of the request message if the device ID does not match the privatization level.

[0103] Furthermore, the judgment module 20 is also used for:

[0104] The privatization level is determined by querying a preset privatization level table based on the service ID, wherein the privatization level is a first level, a second level, or a third level;

[0105] The sender of the request message is determined based on the device ID, wherein the sender is an external device, an on-board ECU, or a target diagnostic function;

[0106] Based on the sending end and the privatization level, it is determined whether the device ID matches the privatization level.

[0107] Furthermore, the data security protection device is also used for:

[0108] If the sending end is an external device, and the privatization level is level one or level two, then it is determined that the device ID does not match the privatization level; or,

[0109] If the sending end is an external device and the privatization level is level three, then the device ID is determined to match the privatization level; or,

[0110] If the sending end is an in-vehicle ECU and the privatization level is Level 1, then it is determined that the device ID does not match the privatization level; or,

[0111] If the sending end is an in-vehicle ECU, and the privatization level is level two or level three, then it is determined that the device ID matches the privatization level; or,

[0112] If the sending end is a target diagnostic function, and the privatization level is level one, level two, or level three, then it is determined that the device ID matches the privatization level.

[0113] Furthermore, the data security protection device is also used for:

[0114] If the device ID matches the privatization level, then the request message is determined to have access rights.

[0115] Furthermore, the data security protection device is also used for:

[0116] Based on the service ID, determine the diagnostic data and / or diagnostic function corresponding to the request message, and return the diagnostic data and / or execute the diagnostic function.

[0117] Furthermore, the data security protection device is also used for:

[0118] Pre-define the privatization level corresponding to each service ID and configure the privatization level table.

[0119] Furthermore, the data security protection device is also used for:

[0120] If an active wake-up command is received, it is determined that the active wake-up command has access rights, and the diagnostic data corresponding to the active wake-up command is returned and / or the diagnostic function corresponding to the active wake-up command is executed.

[0121] The methods performed by the above-mentioned data security protection device can be referred to in various embodiments of the data security protection method of the present invention, and will not be repeated here.

[0122] Furthermore, this invention also proposes a data security protection device, which includes: a memory, a processor, and a data security protection program stored in the memory and executable on the processor. When the data security protection program is executed by the processor, it implements the steps of the data security protection method described above.

[0123] Furthermore, embodiments of the present invention also propose a computer-readable storage medium storing a data security protection program, which, when executed by a processor, implements the steps of the data security protection method described above.

[0124] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0125] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0126] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0127] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A data security protection method, characterized by, The data security protection method comprises the following steps: If a request message is received, the request message is parsed to obtain a device ID and a service ID contained in the request message; wherein the device ID is a unique identifier corresponding to the sending end of the request message, and the service ID is a unique identifier corresponding to the service accessed by the request message; Obtain the private level corresponding to the service ID, and determine whether the device ID matches the private level; If the device ID does not match the private level, access of the request message is rejected; The step of obtaining the private level corresponding to the service ID and determining whether the device ID matches the private level comprises: Based on the service ID, the private level is determined by querying in a preset private level table, wherein the private level is a first level, a second level or a third level; Based on the sending end of the request message, the sending end is determined, wherein the sending end is an external device, a vehicle-mounted ECU or a target diagnostic function; Based on the sending end and the private level, it is determined whether the device ID matches the private level; Wherein, the external device matches the third level, the vehicle-mounted ECU matches the second level and the third level, and the target diagnostic function matches the first level, the second level and the third level; The step of determining whether the device ID matches the private level based on the sending end and the private level comprises: If the sending end is an external device and the private level is a first level or a second level, it is determined that the device ID does not match the private level; or, If the sending end is an external device and the private level is a third level, it is determined that the device ID matches the private level; or, If the sending end is a vehicle-mounted ECU and the private level is a first level, it is determined that the device ID does not match the private level; or, If the sending end is a vehicle-mounted ECU and the private level is a second level or a third level, it is determined that the device ID matches the private level; or, If the sending end is a target diagnostic function and the private level is a first level, a second level or a third level, it is determined that the device ID matches the private level.

2. The data security protection method of claim 1, wherein, After the step of obtaining the private level corresponding to the service ID and determining whether the device ID matches the private level, the following steps are further included: If the device ID matches the private level, it is determined that the request message has access rights.

3. The data security protection method of claim 1, wherein, After the step of determining that the device ID matches the private level, the following steps are further included: Based on the service ID, the diagnostic data and / or diagnostic function corresponding to the request message are determined, and the diagnostic data are returned and / or the diagnostic function is executed.

4. The data security protection method of claim 1, wherein, Before the step of receiving a request message and parsing the request message to obtain a device ID and a service ID contained in the request message, the following steps are further included: The private level corresponding to each service ID is preset, and a private level table is configured.

5. The data security protection method according to any one of claims 1 to 4, wherein, The data security protection method further includes: If the active wake-up instruction is received, it is determined that the active wake-up instruction has access authority, and the diagnostic data corresponding to the active wake-up instruction is returned and / or the diagnostic function corresponding to the active wake-up instruction is executed.

6. A data security device, characterized by The data security protection device includes: The analysis module is configured to, if a request message is received, analyze the request message to obtain a device ID and a service ID contained in the request message, wherein the device ID is a unique identifier corresponding to a sending end of the request message, and the service ID is a unique identifier corresponding to a service accessed by the request message. The judgment module is configured to obtain a private level corresponding to the service ID, and determine whether the device ID matches the private level. The determination module is configured to, if the device ID does not match the private level, reject access of the request message. The obtaining of the private level corresponding to the service ID and the determination of whether the device ID matches the private level include: Based on the service ID, the private level is determined by querying a preset private level table, wherein the private level is a first level, a second level, or a third level. Based on the sending end of the request message, the sending end is determined, wherein the sending end is an external device, a vehicle-mounted ECU, or a target diagnostic function. Based on the sending end and the private level, it is determined whether the device ID matches the private level. The external device matches the third level, the vehicle-mounted ECU matches the second level and the third level, and the target diagnostic function matches the first level, the second level, and the third level. Based on the sending end and the private level, it is determined whether the device ID matches the private level. If the sending end is an external device and the private level is the first level or the second level, it is determined that the device ID does not match the private level; or If the sending end is an external device and the private level is the third level, it is determined that the device ID matches the private level; or If the sending end is a vehicle-mounted ECU and the private level is the first level, it is determined that the device ID does not match the private level; or If the sending end is a vehicle-mounted ECU and the private level is the second level or the third level, it is determined that the device ID matches the private level; or If the sending end is a target diagnostic function and the private level is the first level, the second level, or the third level, it is determined that the device ID matches the private level.

7. A data security appliance, comprising: The data security protection device includes a memory, a processor, and a data security protection program stored on the memory and executable on the processor, and the data security protection program is executed by the processor to implement the steps of the data security protection method of any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, The readable storage medium has a data security protection program stored thereon, and the data security protection program is executed by the processor to implement the steps of the data security protection method of any one of claims 1 to 5.

Images