Internet of Vehicles interface data security verification method and device, vehicle, medium and product
By identifying and processing the request parameter attribute types of the Internet of Vehicles interface and using recursive parsing and sorting rules to generate the target request parameter sequence and signature, the problem that the interface cannot adapt to complex request parameter formats is solved, and the compatibility and security verification flexibility of complex structures such as List and Map are achieved.
Patent Information
- Application Number
- CN202510810706.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-17
- Publication Date
- 2025-09-16
AI Technical Summary
In the existing technology, the request parameter format of the Internet of Vehicles interface is fixed and cannot adapt to complex request parameter formats, resulting in the inability to adapt the interface.
By identifying the attribute type of the request parameter, using recursive parsing and sorting rules to process the request parameter, the target request parameter sequence and signature are generated, achieving compatibility with complex structures such as List and Map without modifying the existing interface type.
The compatibility of the interface has been improved, and it is compatible with complex structures such as List and Map without modifying the existing interface, achieving flexibility and versatility of security verification.
Smart Images
Figure CN120658402A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle networking technology, and in particular to a vehicle networking interface data security verification method, device, vehicle, medium and product. Background Art
[0002] In the communication between domestic Internet of Vehicles APP (Application) and TSP (Electrical Service Provider), the APP is required to send or receive data as set M1, sort the parameters of set M1 with non-empty parameter values from small to large according to the parameter name ASCII code, and use the URL key-value pair format to splice them into a string stringA, then perform a digest parameter signature on stringA to obtain a signature. Finally, during the transmission process, all data sets are converted into a JSON string for transmission.
[0003] The receiving TSP needs to use a string to receive the entire parameter set. The receiving party needs to convert the request parameters from a string into an object before using it. Based on this situation, there are certain limitations on interface design when using this method. The request parameters of the interface must be of string type, and then the string must be converted into an object before it can be used. Secondly, this function cannot be applied to existing functions and can only be used after the request parameters are modified. Summary of the Invention
[0004] The present application provides a method, device, vehicle, medium and product for verifying the security of data in an Internet of Vehicles interface to solve the problems in related technologies such as the inability to adapt to complex request parameter formats, the fixed request parameter formats, and the inability to adapt the interface.
[0005] The first aspect of the present application provides a method for security verification of Internet of Vehicles interface data, comprising the following steps: identifying the attribute type of at least one request parameter in the request data of an Internet of Vehicles application, wherein the request data is the request data sent by the Internet of Vehicles application to the target interface in the TSP; if the attribute type is the first type, recursively parsing the sub-request parameters in the corresponding request parameters, and sorting the sub-request parameters of the request parameters based on the sorting rules to obtain a first request parameter sequence; if the attribute type is the second type, sorting the request parameters based on the sorting rules to obtain a second request parameter sequence; generating a target request parameter sequence based on the first request parameter sequence and the second request parameter sequence, generating a target string and a signature based on the target request parameter sequence, and sending the signature and the target request parameter sequence to the TSP for security verification of the request data of the target interface, wherein the TSP performs security verification on the signature based on the target request parameter sequence, and transmits the request parameters to the target interface after the security verification passes.
[0006] Optionally, in one embodiment of the present application, generating a target string and a signature based on a target request parameter sequence includes: concatenating the request parameters in the request parameter sequence into a corresponding target string according to a target format, and generating a signature based on the target string.
[0007] Optionally, in one embodiment of the present application, generating a signature based on a target string includes: concatenating a key at the end of the target string to obtain a first string; concatenating a timestamp at the end of the first string to obtain a second string; and performing a target secure hash algorithm operation on the second string to obtain a signature.
[0008] Optionally, in one embodiment of the present application, the target format is a uniform resource locator key-value pair format.
[0009] Optionally, in one embodiment of the present application, a target request parameter sequence is generated based on the first request parameter sequence and the second request parameter sequence, including: deleting request parameters with empty values in the first request parameter sequence and the second request parameter sequence; and sorting the request parameters in the first request parameter sequence and the second request parameter sequence according to corresponding ASCII code values to generate a target request parameter sequence.
[0010] Optionally, in one embodiment of the present application, the first type includes at least one of a list type, a mapping type, and a set type, and the second type includes at least one of an integer type, a string type, a Boolean type, and a floating-point type.
[0011] The second aspect of the present application provides a device for verifying the security of Internet of Vehicles interface data, including: an identification module for identifying the attribute type of at least one request parameter in the request data of an Internet of Vehicles application, wherein the request data is the request data sent by the Internet of Vehicles application to the target interface in the TSP; a parsing module for recursively parsing the sub-request parameters in the corresponding request parameters if the attribute type is the first type, and sorting the sub-request parameters of the request parameters based on the sorting rules to obtain a first request parameter sequence; a sorting module for sorting the request parameters based on the sorting rules to obtain a second request parameter sequence if the attribute type is the second type; a verification module for generating a target request parameter sequence according to the first request parameter sequence and the second request parameter sequence, generating a target string and a signature based on the target request parameter sequence, and sending the signature and the target request parameter sequence to the TSP for security verification of the request data of the target interface, wherein the TSP performs security verification on the signature based on the target request parameter sequence, and transmits the request parameters to the target interface after the security verification passes.
[0012] Optionally, in one embodiment of the present application, the verification module is further used to: splice the request parameters in the request parameter sequence into a corresponding target string according to the target format, and generate a signature based on the target string.
[0013] Optionally, in one embodiment of the present application, the verification module is further used to: concatenate a key at the end of a target string to obtain a first string; concatenate a timestamp at the end of the first string to obtain a second string; and perform a target secure hash algorithm operation on the second string to obtain a signature.
[0014] Optionally, in one embodiment of the present application, the target format is a uniform resource locator key-value pair format.
[0015] Optionally, in one embodiment of the present application, the verification module is further used to: delete the request parameters with empty values in the first request parameter sequence and the second request parameter sequence; sort the request parameters in the first request parameter sequence and the second request parameter sequence according to the corresponding ASCII code values to generate a target request parameter sequence.
[0016] Optionally, in one embodiment of the present application, the first type includes at least one of a list type, a mapping type, and a set type, and the second type includes at least one of an integer type, a string type, a Boolean type, and a floating-point type.
[0017] The third aspect of the present application provides a vehicle, comprising: a memory, a processor, and a computer program stored in the memory and runnable on the processor. The processor executes the program to perform the vehicle network interface data security verification method as described in the above embodiment.
[0018] The fourth aspect of the present application provides a computer-readable storage medium on which a computer program or instruction is stored. The computer program or instruction is executed by a processor to perform the vehicle network interface data security verification method as described in the above embodiment.
[0019] The fifth embodiment of the present application provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed, the method for security verification of vehicle network interface data as described in the above embodiment is implemented.
[0020] Therefore, this application has at least the following beneficial effects:
[0021] In an embodiment of the present application, when the request data includes a first type of request parameter, recursive parsing can be used to parse and obtain sub-request parameters, eliminating the need to force the request parameter to be of type String and making it compatible with complex structures such as List and Map. Furthermore, by automatically parsing the parameters recursively, the old interface can be used without modifying the parameter type, thereby improving compatibility. Furthermore, based on the first type of request parameter and the first request parameter sequence and the second request parameter sequence generated based on the second type of request parameter, respectively, a target request parameter sequence is generated, and the target request parameter sequence and signature are sent to the TSP for security verification. This solves technical problems in related technologies such as the inability to adapt to complex request parameter formats and the inability to adapt interfaces due to fixed request parameter formats.
[0022] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which:
[0024] Figure 1 Flowchart of a method for verifying the security of vehicle network interface data according to an embodiment of the present application;
[0025] Figure 2 A schematic diagram of a process for recursively parsing traversal request parameters according to an embodiment of the present application;
[0026] Figure 3 This is a comparative diagram of the APP-side signing process provided in accordance with an embodiment of the present application;
[0027] Figure 4 A schematic diagram comparing the TSP signature verification process according to an embodiment of the present application;
[0028] Figure 5 This is an example diagram of a vehicle networking interface data security verification device provided according to an embodiment of the present application;
[0029] Figure 6 A schematic structural diagram of a vehicle provided according to an embodiment of the present application. DETAILED DESCRIPTION
[0030] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.
[0031] The following describes the vehicle network interface data security verification method, device, vehicle, medium and product of the embodiment of the present application with reference to the accompanying drawings. In response to the problem mentioned in the above background technology that the request parameters of the existing interface must be of string type and then converted into objects before they can be used, and secondly, the function cannot be applied to existing functions and the request parameters must be modified before they can be used, the present application provides a vehicle network interface data security verification method. In this method, when the request data includes a first type of request parameter, a recursive parsing method is used to parse and obtain a sub-request parameter, thereby eliminating the need to force the request parameter to be of string type and being compatible with complex structures such as List and Map. By automatically parsing the parameters recursively, the old interface can be used without modifying the parameter type, thereby improving compatibility. Based on the first type of request parameter and the first request parameter sequence and the second request parameter sequence generated based on the second type of request parameter, a target request parameter sequence is generated, and the target request parameter sequence and signature are sent to the TSP for security verification. Thus, the problem that the related art cannot adapt to complex request parameter formats and the request parameter format is fixed, resulting in the inability to adapt the interface is solved.
[0032] Specifically, Figure 1 A flowchart of a method for verifying the security of data on an Internet of Vehicles interface provided in an embodiment of the present application.
[0033] like Figure 1 As shown, the vehicle network interface data security verification method includes the following steps:
[0034] In step S101 , the attribute type of at least one request parameter in request data of an Internet of Vehicles application is identified, wherein the request data is request data sent by the Internet of Vehicles application to a target interface in a TSP.
[0035] It is understandable that the embodiment of the present application can identify the attribute type of at least one request parameter in the request data received by the Internet of Vehicles target interface to facilitate the subsequent splitting of the request parameters.
[0036] In step S102, if the attribute type is the first type, the sub-request parameters in the corresponding request parameters are recursively parsed, and the sub-request parameters of the request parameters are sorted based on the sorting rule to obtain a first request parameter sequence.
[0037] The first type is a complex data structure, including at least one of list type, mapping type, and collection type, which can be List, map, list <map>、map<String,list> etc.; the sorting rule can be sorting from small to large according to ASCII code.
[0038] It is understandable that, in an embodiment of the present application, when the attribute type of a request parameter is the first type, the sub-request parameter in the corresponding request parameter can be recursively parsed, and the request parameter can be sorted based on the sorting rule to obtain a first request parameter sequence, thereby eliminating the need to force the request parameter to be of String type and being compatible with complex structures such as List and Map. Furthermore, by automatically parsing parameters recursively, the old interface can be used without modifying the parameter type, thereby improving compatibility.
[0039] In step S103, if the attribute type is the second type, the request parameters are sorted based on the sorting rule to obtain a second request parameter sequence.
[0040] The second type is a basic data type, including at least one of an integer type, a string type, a Boolean type, and a floating-point type.
[0041] It is understandable that, in the embodiment of the present application, when the attribute type of the request parameter is the second type, the request parameters can be directly sorted based on the sorting rule to obtain the second request parameter sequence.
[0042] In step S104, a target request parameter sequence is generated according to the first request parameter sequence and the second request parameter sequence, a target character string and a signature are generated based on the target request parameter sequence, and the signature and the target request parameter sequence are sent to the TSP for security verification of the request data of the target interface, wherein the TSP performs security verification on the signature based on the target request parameter sequence, and transmits the request parameters to the target interface after the security verification passes.
[0043] It can be understood that the embodiment of the present application can generate a target request parameter sequence based on the first request parameter sequence and the second request parameter sequence, and generate a target string and a signature based on the target request parameter sequence, and send the signature and the target request parameter sequence to the TSP for security verification of the request data of the target interface. After the verification is passed, the parameters are transmitted to the target interface.
[0044] In an embodiment of the present application, a target request parameter sequence is generated based on the first request parameter sequence and the second request parameter sequence, including: deleting the request parameters with empty values in the first request parameter sequence and the second request parameter sequence; and sorting the request parameters in the first request parameter sequence and the second request parameter sequence according to the corresponding ASCII code values to generate the target request parameter sequence.
[0045] It can be understood that the embodiment of the present application can delete the empty request parameters in the parameter sequence so that they do not participate in the signature operation, improve the operation efficiency, and sort them in the ASCII code dictionary order of the request parameter name to generate the target parameter sequence, avoid inconsistent sorting rules due to language or platform differences, and ensure the verifiability of the signature.
[0046] In an embodiment of the present application, a target string and a signature are generated based on a target request parameter sequence, including: concatenating the request parameters in the request parameter sequence into a corresponding target string according to a target format, and generating a signature based on the target string.
[0047] The target format is a uniform resource locator key-value pair format, that is, a URL key-value pair format, key1=value1&key2=value2.
[0048] It can be understood that the embodiment of the present application can splice the request parameters in the request parameter sequence into the corresponding target string according to the target format, and generate a signature based on the target string. Since the URL key-value pair format is a universal standard, it is convenient for different systems to parse parameters, reduce the interface docking cost, and provide a unified format to reduce parameter processing ambiguity, ensuring that the signature generation and verification process are consistent.
[0049] In an embodiment of the present application, generating a signature based on a target string includes: concatenating a key at the end of the target string to obtain a first string; concatenating a timestamp at the end of the first string to obtain a second string; and performing a target secure hash algorithm operation on the second string to obtain a signature.
[0050] Among them, the key secretKey is the encryption key issued offline by the TSP and is used for signature generation; the timestamp is the time stamp in the request header, which is used to prevent signature replay attacks; the target secure hash algorithm can be the SHA256 algorithm, which is used to generate an irreversible hash value.
[0051] It can be understood that the embodiment of the present application can splice the key at the end of the target string to obtain a first string, splice the timestamp at the end of the first string to obtain a second string, and perform the target secure hash algorithm operation on the second string to obtain a signature.
[0052] Specifically, the embodiment of the present application can concatenate the key secretKey to the end of the target string stringA to obtain the first stringSignTemp string, concatenate the timestamp timestamp (in the Header) to the end of stringSignTemp to obtain the second stringSignTemp2 string, and perform a SHA256 operation on stringSignTemp2, output the SHA256 operation result into a Base64 format string, and then convert all characters of the obtained string to uppercase to obtain the sign value signValue.
[0053] Specifically, the current interface security verification scheme of the domestic Internet of Vehicles platform has a fixed type requirement for the interface request parameters, which must be String type request parameters, which has certain limitations on the interface type. Secondly, this method is not applicable to the existing old interfaces. It is necessary to transform the request parameters, change the request parameters to String type, and then convert the request parameters into corresponding entity objects before they can be used. The present application uses a recursive method to implement the parsing of attribute types in the request parameters. Special types such as List and Map need to be processed separately. The list and map in the entire request set must be traversed until the parameter object no longer contains the special format of the list or map type. The other parameters are sorted according to the sorting rules. Because the List needs to parse the attributes inside and sort according to the sorting rules, and the Map is unordered, it also needs to be sorted according to specific rules, and a string is generated based on the sorted request parameters. The process of traversing the request parameters based on the attribute type and parsing is as follows. Figure 2 As shown, the comparison between this application and the current verification scheme is as follows Figure 3 and Figure 4 As shown, Figure 3 To describe the signing process from the APP side, Figure 4 This section describes the signature verification process from the TSP side. Similarly, the TSP signature verification side can verify the signature of the request parameters through a recursive algorithm. The process is similar to the signature addition process.
[0054] The signature generation process in the request parameter of the embodiment of the present application includes:
[0055] In the first step, assume that all the data sent or received is set M1, sort the parameters with non-empty parameter values in set M1 from small to large according to the ASCII code of the parameter name (lexicographical order), and use the URL key-value pair format (i.e. key1=value1&key2=value2...) to splice them into string A.
[0056] The signature methods in the request parameters include:
[0057] 1. The signature algorithm uses SHA256;
[0058] 2. Both the service provider and the consumer need to verify the signature;
[0059] 3. Signature generation steps.
[0060] In addition, it should be noted that the ASCII codes of the request parameter names are sorted from small to large (lexicographical order); if the value of the request parameter is empty, it will not be included in the signature; the request parameter names are case-sensitive; when verifying the call return signature, the transmitted sign parameter does not participate in the signature, and the generated signature will be verified with the sign value; the TSP interface may add fields, and the added extended fields must be supported when verifying the signature.
[0061] The second step is to concatenate secretKey to stringA to obtain stringSignTemp, and then concatenate timestamp (in the header) to stringSignTemp to obtain stringSignTemp2. SHA256 operation is performed on stringSignTemp2, and the SHA256 operation result is output as a Base64 format string. Then all characters of the obtained string are converted to uppercase to obtain the sign value signValue. Among them, secretKey is issued offline by the TSP platform.
[0062] The following describes the vehicle network interface data security verification method of the present application through a specific embodiment.
[0063] In this embodiment, a SpringBoot project environment needs to be created, which relies on static parameters. These parameters need to be configured based on the key value used for signature verification for different callers or constraints between two parties. The following is an example of the settings in a file with a .yaml extension:
[0064] sdkconfig:
[0065] supplierinfo:
[0066] list:
[0067] -{appId:xxx,secretKey:xxx}
[0068] The specific steps are as follows:
[0069] Step 001: Create a SpringBoot project;
[0070] Step 002: Define a configuration file with the extension .yaml (this configuration method parameter is the configuration standard of the SpringBoot project) and set the static parameter key value;
[0071] Step 003: Introduce the Maven coordinate system of the SDK of this application;
[0072] Step 004: Define the interface class of the Controller layer and add the annotation @InternationalSdkSign to the method body that needs to be signed to complete the signature verification of the request parameters and the signing of the response parameters.
[0073] The development language used in this application can be Java language, and the components rely on the Spring ecological environment. Spring's AOP aspect technology is used to implement global and unified verification of the request parameters of the project and signing of the response parameters. The implementation is simple. It only requires marking the relevant annotations on the method body corresponding to the Controller layer of the interface. By using recursive traversal parameters, there is no need to care about the request parameters of the interface, nor is there any need to modify the interface.
[0074] This application uses Spring's aspect technology to implement interception operations on requests and responses to verify and sign parameters. It only requires the introduction of the Maven dependency package and the addition of annotations to the interfaces that need to be verified for security. There is no need to modify the interface request parameters, and it can be used out of the box. It is also applicable to existing old interfaces without any modification.
[0075] According to the method for security verification of Internet of Vehicles interface data proposed in the embodiment of the present application, when the request data includes a first type of request parameter, recursive parsing can be used to parse it to obtain a sub-request parameter, thereby eliminating the need to force the request parameter to be of String type and being compatible with complex structures such as List and Map. By automatically parsing the parameters recursively, the old interface can be used without modifying the parameter type, thereby improving compatibility. Based on the first type of request parameter and the first request parameter sequence and the second request parameter sequence generated based on the second type of request parameter, respectively, a target request parameter sequence is generated, and the target request parameter sequence and the signature are sent to the TSP for security verification.
[0076] Next, the vehicle network interface data security verification device proposed in accordance with an embodiment of the present application will be described with reference to the accompanying drawings.
[0077] Figure 5 It is a block diagram of the vehicle network interface data security verification device of an embodiment of the present application.
[0078] like Figure 5 As shown, the vehicle network interface data security verification device 10 includes: an identification module 100, a parsing module 200, a sorting module 300 and a verification module 400.
[0079] Among them, the identification module 100 is used to identify the attribute type of at least one request parameter in the request data of the Internet of Vehicles application, wherein the request data is the request data sent by the Internet of Vehicles application to the target interface in the TSP; the parsing module 200 is used to recursively parse the sub-request parameters in the corresponding request parameters if the attribute type is the first type, and sort the sub-request parameters of the request parameters based on the sorting rules to obtain a first request parameter sequence; the sorting module 300 is used to sort the request parameters based on the sorting rules to obtain a second request parameter sequence if the attribute type is the second type; the verification module 400 is used to generate a target request parameter sequence according to the first request parameter sequence and the second request parameter sequence, generate a target string and signature based on the target request parameter sequence, and send the signature and target request parameter sequence to the TSP for security verification of the request data of the target interface, wherein the TSP performs security verification on the signature based on the target request parameter sequence, and transmits the request parameters to the target interface after the security verification passes.
[0080] In the embodiment of the present application, the verification module 400 is further used to: splice the request parameters in the request parameter sequence into a corresponding target string according to the target format, and generate a signature based on the target string.
[0081] In an embodiment of the present application, the verification module 400 is further used to: concatenate a key at the end of a target string to obtain a first string; concatenate a timestamp at the end of the first string to obtain a second string; and perform a target secure hash algorithm operation on the second string to obtain a signature.
[0082] In the embodiment of the present application, the target format is a uniform resource locator key-value pair format.
[0083] In an embodiment of the present application, the verification module 400 is further used to: delete the request parameters with empty values in the first request parameter sequence and the second request parameter sequence; sort the request parameters in the first request parameter sequence and the second request parameter sequence according to the corresponding ASCII code values to generate a target request parameter sequence.
[0084] In an embodiment of the present application, the first type includes at least one of a list type, a mapping type, and a set type, and the second type includes at least one of an integer type, a string type, a Boolean type, and a floating-point type.
[0085] It should be noted that the aforementioned explanation of the embodiment of the vehicle network interface data security verification method is also applicable to the vehicle network interface data security verification device of this embodiment, and will not be repeated here.
[0086] According to the vehicle network interface data security verification device proposed in the embodiment of the present application, when the request data includes a first type of request parameter, a recursive parsing method can be used to parse the sub-request parameter, thereby eliminating the need to force the request parameter to be of String type and being compatible with complex structures such as List and Map. By automatically parsing the parameters recursively, the old interface can be used without modifying the parameter type, thereby improving compatibility. A target request parameter sequence is generated based on the first type of request parameter and the second request parameter sequence generated based on the second type of request parameter, and the target request parameter sequence and the signature are sent to the TSP for security verification.
[0087] Figure 6 A schematic diagram of the structure of a vehicle provided in an embodiment of the present application. The vehicle may include:
[0088] A memory 601 , a processor 602 , and a computer program stored in the memory 601 and executable on the processor 602 .
[0089] When the processor 602 executes the program, the vehicle network interface data security verification method provided in the above embodiment is implemented.
[0090] Furthermore, the vehicle further comprises:
[0091] The communication interface 603 is used for communication between the memory 601 and the processor 602 .
[0092] The memory 601 is used to store computer programs that can be run on the processor 602 .
[0093] The memory 601 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.
[0094] If the memory 601, processor 602, and communication interface 603 are implemented independently, the communication interface 603, memory 601, and processor 602 can be interconnected via a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.
[0095] Optionally, in a specific implementation, if the memory 601, the processor 602 and the communication interface 603 are integrated on a chip, the memory 601, the processor 602 and the communication interface 603 can communicate with each other through an internal interface.
[0096] The processor 602 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.
[0097] An embodiment of the present application also provides a computer-readable storage medium on which a computer program or instruction is stored. When the computer program or instruction is executed by a processor, the above-mentioned vehicle network interface data security verification method is implemented.
[0098] An embodiment of the present application also provides a computer program product, including a computer program or instructions, which, when executed, implements the above-mentioned method for security verification of vehicle network interface data.
[0099] In the description of this specification, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and the features of different embodiments or examples without contradiction.
[0100] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature specified as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the description of this application, "N" means at least two, for example, two, three, etc., unless otherwise specifically defined.
[0101] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, fragment or portion of code comprising one or N executable instructions for implementing a custom logical function or process step, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed in a different order than shown or discussed, including performing functions in a substantially simultaneous manner or in a reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application pertain.
[0102] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, it can be implemented using any one or a combination of the following technologies known in the art: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array, a field programmable gate array, etc.
[0103] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.< / map>
Claims
1. A method for verifying the security of vehicle network interface data, characterized in that: The following steps are involved: Identifying an attribute type of at least one request parameter in request data of an Internet of Vehicles application, wherein the request data is request data sent by the Internet of Vehicles application to a target interface in a TSP; If the attribute type is the first type, recursively parsing the sub-request parameters in the corresponding request parameters, and sorting the sub-request parameters of the request parameters based on the sorting rule to obtain a first request parameter sequence; If the attribute type is the second type, sorting the request parameters based on the sorting rule to obtain a second request parameter sequence; A target request parameter sequence is generated according to the first request parameter sequence and the second request parameter sequence, a target character string and a signature are generated based on the target request parameter sequence, and the signature and the target request parameter sequence are sent to the TSP for security verification of the request data of the target interface, wherein the TSP performs security verification on the signature based on the target request parameter sequence, and transmits the request parameters to the target interface after the security verification passes.
2. The method for verifying the security of the Internet of Vehicles interface data according to claim 1, characterized in that: Generating a target character string and a signature based on the target request parameter sequence includes: The request parameters in the request parameter sequence are spliced into a corresponding target character string according to a target format, and a signature is generated based on the target character string.
3. The method for verifying the security of the Internet of Vehicles interface data according to claim 1, characterized in that: Generating a signature based on the target character string includes: Adding a key to the end of the target character string to obtain a first character string; Adding a timestamp to the end of the first character string to obtain a second character string; Perform a target secure hash algorithm operation on the second character string to obtain the signature.
4. The method for verifying the security of vehicle network interface data according to claim 2, characterized in that: The target format is a uniform resource locator key-value pair format.
5. The method for verifying the security of vehicle network interface data according to claim 1, characterized in that: Generating a target request parameter sequence according to the first request parameter sequence and the second request parameter sequence includes: Deleting request parameters with empty values in the first request parameter sequence and the second request parameter sequence; The request parameters in the first request parameter sequence and the second request parameter sequence are sorted according to corresponding ASCII code values to generate the target request parameter sequence.
6. The method for verifying the security of vehicle network interface data according to claim 1, characterized in that: The first type includes at least one of a list type, a mapping type, and a set type, and the second type includes at least one of an integer type, a string type, a Boolean type, and a floating-point type.
7. A vehicle network interface data security verification device, characterized in that: include: an identification module, configured to identify an attribute type of at least one request parameter in request data of an Internet of Vehicles application, wherein the request data is request data sent by the Internet of Vehicles application to a target interface in the TSP; a parsing module, configured to, if the attribute type is the first type, recursively parse the sub-request parameters in the corresponding request parameters, and sort the sub-request parameters of the request parameters based on a sorting rule to obtain a first request parameter sequence; a sorting module, configured to, if the attribute type is the second type, sort the request parameters based on a sorting rule to obtain a second request parameter sequence; a verification module, configured to generate a target request parameter sequence based on the first request parameter sequence and the second request parameter sequence, generate a target character string and a signature based on the target request parameter sequence, and send the signature and the target request parameter sequence to the TSP for security verification of the request data of the target interface, wherein the TSP performs a security verification on the signature based on the target request parameter sequence and transmits the request parameters to the target interface after the security verification passes.
8. A vehicle, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the vehicle network interface data security verification method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: The computer program or instruction is executed by a processor to implement the vehicle network interface data security verification method as described in any one of claims 1-6.
10. A computer program product comprising a computer program or instructions, characterized in that When the computer program or instruction is executed, the vehicle network interface data security verification method as described in any one of claims 1 to 6 is implemented.