GB/T 47467-2026Specification for the security management interface of the internet of vehicles (English PDF)

5.2 Communication Transmission Requirements

5.2.1 Data Reporting Frequency Data should be filled in completely according to the information format described in Chapter 7, and transmitted according to the reporting frequency requirements. The submission of various types of data... The reporting frequency requirements are as specified in Tables 1 and 2.

5.2.2 Data Encoding Format Requirements The data encoding format requirements are as follows:

a) Data reported by enterprise-side platforms and data distributed by national-side platforms should uniformly use UTF-8 encoding;

b) Enterprise-side platforms and national-side platforms should use JSON format for data interaction.

5.2.3 Data Security Requirements Data security requirements are as follows:

a) Enterprise-side platforms and national-side platforms should uniformly use secure communication protocols of TLS

1.2 or higher, or at least equivalent security level. To establish a secure communication connection, TLS certificates should uniformly be those issued by the national platform.

b) Data reporting from enterprise-side platforms and data distribution from national-side platforms should be conducted using commercial cryptography that conforms to national standards. The encryption algorithm key is generated and provided by the national platform, while each enterprise platform has its own unique key.

c) Sensitive information such as VIN, longitude, and latitude should be uploaded after security processing without affecting business operations;

d) Malicious files, traffic files, and evidence files on the enterprise-side platform should be reported to the national-side platform via SFTP. SFTP authentication keys are produced and provided by the national platform, while each enterprise platform has its own unique key.

e) The confidentiality and integrity of sensitive data such as certificates and keys should be ensured during transmission;

f) Sensitive data such as certificates and keys should be stored in a secure and trusted storage space.

5.3 Data Interaction Process

5.3.1 Data Reporting The data reporting process is shown in Figure 2, and the requirements are as follows:

a) Enterprise-side platforms should report data to the national-side platform through data reporting interfaces;

b) After receiving and parsing the data, the national platform performs data verification to check for errors in the data format. If errors are found, the data verification should fail. The information is sent to the enterprise-side platform;

c) After receiving a data verification failure message, the enterprise-side platform should ensure that the data meets the requirements before re-uploading.

5.3.2 Command Interaction The instruction interaction process is shown in Figure 3, and the requirements are as follows:

a) Command information generated by the national platform should be sent to the enterprise platform through the command interaction interface;

b) When an enterprise-side platform executes instructions, the data generated during the execution process should be reported to the national-side platform (maximum single file size 512MB, if...). If the file size exceeds the limit, it should be split into multiple files for uploading.

c) During the execution of instructions on the enterprise-side platform, the execution status should be reported to the national-side platform regularly in accordance with the requirements of 8.3.2.

6.1 Data Reporting Interface

6.1.1 Basic Resource Data for Vehicle-to-Everything (V2X) After adding or updating basic vehicle-to-everything (V2X) resource data locally, the enterprise-side platform should report the added or updated data to the national-side platform. Taiwan's basic telecommunications operators should report data including enterprise entity information, while vehicle-to-everything (V2X) related enterprises should report data including enterprise entity information. Information such as vehicle networking platform information and basic vehicle information.

6.1.2 Networked vehicle operating status data Enterprise-side platforms of connected car manufacturers should promptly report the operational status data of connected vehicles to the national platform.

6.1.3 Vehicle Network Security Data Basic telecommunications operators' enterprise-side platforms should promptly report vehicle-to-everything (V2X) related security data to the national platform, including malicious programs. Information such as sequence information and network attack information. Enterprises involved in the Internet of Vehicles (IoV) should promptly report security data related to their IoV platforms and connected vehicles to the national platform. The platform includes information on malicious programs, cyberattacks, and security vulnerabilities.

6.2 Command Interaction Interface

6.2.1 Issuance of Commands The national platform can generate monitoring instructions and communication log query instructions as needed and send them to the enterprise platform.

6.2.2 Command Status Feedback After receiving monitoring instructions and communication log query instructions from the national platform, the enterprise-side platform should report the execution of the instructions to the national platform. Row status.

6.2.3 Command Result Feedback After receiving monitoring instructions and communication log query instructions from the national platform, the enterprise-side platform should report the execution of the instructions to the national platform. Result.

7.1 Basic Resource Data for Vehicle-to-Everything (V2X)

7.1.1 Enterprise Entity Information Basic telecommunications operators' enterprise-side platforms should report the information of the enterprise entities providing services to the national platform, including information on vehicle-to-everything (V2X) related enterprises. Enterprise-side platforms should report their corporate information to the national platform. Corporate information includes the company name, major industry category, and sub-industry category. Information such as category, registered province, and reporting time is shown in Table 3.

7.1.2 Vehicle Networking Platform Information

7.1.2.1 Basic Information of the Vehicle Networking Platform Enterprise-side platforms of companies involved in vehicle networking should report basic information about their vehicle networking platforms to the national platform, including the platform name and the names of the connected car companies. Information such as quantity and names of connected car manufacturers is shown in Table

4.The initial connection will be reported in full, with subsequent updates to be reported later.

7.2 Networked vehicle operating status data The enterprise-side platforms of connected car manufacturers should report the operational status data of connected vehicles to the national platform (if the vehicle does not collect this data). Information such as company name, vehicle identification number, vehicle status, longitude, and latitude does not need to be reported (see Table 7). The reporting cycle is shortest. The maximum duration should not exceed 30 seconds. When a security incident occurs, data within 30 seconds before and after the incident should be reported, with a reporting cycle not exceeding 1 second. Data from the deceased was transmitted in the form of a replacement.

7.3 Network Security Data for Vehicle-to-Everything (V2X)

7.3.1 Malicious Program Information Enterprise-side platforms should report malicious program information to national-level platforms, including the type of malicious program, affected targets, and malicious sample information. For details, see Table 8.

8.1.1 Monitoring Instructions

8.1.1.1 Traffic Filtering Command The national platform sends traffic filtering instructions to the enterprise platforms of basic telecommunications operators, using the IP five-tuple (source IP, destination IP,...) to filter traffic. Traffic is filtered using rules based on protocol, source port, and destination port. See Table 12 for traffic filtering instructions.

8.1.1.2 Malicious Message Monitoring Commands The national platform issues malicious message monitoring instructions (instruction rules. Snort rules, etc.) to the enterprise platform, and the enterprise platform responds to the instructions. The system monitors the rules contained therein and reports the corresponding security monitoring results to the national platform. Malicious message monitoring instruction information. See Table 13.

8.1.1.3 Malicious File Detection Commands The national platform issues malicious file monitoring instructions to the enterprise platform (instruction rules. destination IP, URL, domain name, sample HASH value,...). (Rules such as YARA descriptions of samples) Enterprise-side platforms should monitor malicious samples contained in instructions and report corresponding data to national-side platforms. Security monitoring results for malicious samples. Malicious file monitoring instructions are shown in Table 14.

8.1.3 Remote Data Security Inspection Command The national platform issues remote data security inspection instructions to the enterprise platform, supporting full or sample retention of data transmission traffic. Data security inspection instructions are shown in Table 16.

9.2 Verification Principles

9.2.1 Interface Data Verification The content and basic requirements for conformity verification are as follows:

a) The content entered in the message type field of test system B should conform to Appendix A;

b) The number and types of parameters reported and interacted by test system B should comply with the requirements of Chapters 7 and 8;

c) Data verification failure information from test system A should be transmitted to test system B via a message queue. Test system B receives the data verification... If you encounter a failure message, please ensure that the data meets the requirements and re-upload it.

9.2.2 Interface Logic Verification The content and basic requirements for conformity verification are as follows:

a) If the parameters of the correct type and format are entered, test system A should not return any messages;

b) Input the error type or format parameter. Test system A should return an error code message that conforms to the specifications in this document. System A should store the corresponding error code reason.

9.2.3 Interface Interoperability Verification The content and basic requirements for conformity verification are as follows:

a) The data sent by test system B should be verified for correctness by test system A;

b) The data returned by test system A should be verified for correctness by test system B;

c) The instructions issued by test system A should be verified for correctness by test system B;

d) The correctness of the instruction status and instruction results fed back by test system B should be verified by test system A.

9.3.1 Verification Scenario for Reporting Interface Functionality

9.3.1.1 Verification Objective The verification of the reporting interface function should check whether test system A meets the functional requirements and reporting interface information provided in Chapters 6 and 7. The information format requires the verification environment described in

9.1 before verification. The algorithm is SM4 as an example.

9.3.1.2 Verification Process The data reporting formats specified in Chapter 7 should be verified. Taking the reporting of basic vehicle network resource data as an example, the other two... The class interface verification process is similar; please refer to the following steps for the verification process.

a) Test system B is configured with a certificate containing an access control list to connect to test system A;

b) Test system B sets the message body according to the interface information format;

c) Test system B calls the SM4 data encryption method to encrypt the uploaded data;

d) Test system B calls the send message method to send encrypted data to test system A;

e) Test system B sets up a listener to monitor messages from test system A, checks for error messages, and if any are returned, checks for errors. When resuming work, ensure the data meets the requirements and then re-upload it;

f) Test system A listens to the message queue and checks whether there are any errors in the data sent by the enterprise-side platform service interface. If correct, it proceeds... If an error occurs, the verification failure information is recorded and simultaneously fed back to the test system B.

9.3.1.3 Passing the standard If the parameters are correct, no error message should be returned, and the data should be stored in the database as required. If the parameters are incorrect, a data validation failure message as specified in section

7.4 should be returned. The system will process the information and discard any erroneous data as required.

9.3.2 Interface Communication Verification Scenarios

9.3.2.1 Verification Objective Testing system A and testing system B work together to use certificates and data encryption for data transmission and communication to ensure channel security. Scenarios where data is not leaked or tampered with.

9.3.2.2 Verification Process To verify the communication transmission requirements in section 5.2, the verification method can refer to the following steps.

a) Test system A uses a network packet capture tool to check whether the data is transmitted encrypted;

b) Test system A uses a network packet capture tool to capture packet data and analyzes the frequency of data transmission of a specified type;

c) Test system A checks whether the encrypted data is UTF-8 encoded and in JSON format by decrypting the encrypted data and printing logs.

d) Test system A to check whether sensitive data is implemented in accordance with de-identification, hashing and other methods.

9.3.2.3 Passing the standard The test results should meet the communication transmission requirements specified in 5.2.

9.3.3 Command Interaction Interface Verification Scenario

9.3.3.1 Verification Objective The instruction interaction interface verification should check whether the instruction interaction conforms to the functional requirements and interface information format provided in Chapters 6 and 8. Before verification, the verification environment described in

9.1 is required. Taking the SM4 algorithm as an example.

Note. SM4 stands for "SM

4 Block Cipher Algorithm," a symmetric encryption algorithm issued by the national cryptography management authority. It is used in my country. It occupies an important position in commercial cryptography systems, mainly used to protect the confidentiality of data and ensure the security of information during transmission.

9.3.3.2 Verification Process The verification of all information formats for command interaction as specified in Chapter 8 should be performed, using the communication log query command as an example to illustrate the verification of monitoring commands. The process now includes a step of uploading sample files and storing them in the database via an HTTPS interface. Other verification procedures can be referenced as follows:

a) Test system A issues a communication log query command to test system B according to the standard format;

b) Test system B listens for the corresponding communication log query command message through the message queue;

c) Test system B queries the relevant communication logs of the vehicle network platform based on the command type and parameters in the communication log query;

d) Test system B will send the communication logs to test system A;

e) Test system B sends the instruction execution status to test system A as required;

f) Test system A receives the status information and result data from test system B, parses and decrypts it for verification, and if correct... If an error occurs, the data verification failure information should be recorded and fed back to the test system B.

9.3.3.3 Passing the standard The execution status and execution result feedback should conform to the message format specified in

8.2 and 8.3, and be stored in the database after verification.