Verification methods, devices, electronic equipment, and storage media for remote vehicle login

Abstract

This invention discloses a method, apparatus, electronic device, and storage medium for verifying remote login to a vehicle, relating to the field of vehicles. The method includes: after the vehicle's infotainment system starts up, detecting an access request command sent by a client; in response to detecting the access request command, performing initial verification on the client based on the access request command to obtain an initial verification result; if the initial verification result indicates that the client is a pre-trusted client, controlling the remote login port of the infotainment system to switch from a hidden state to an open state; and performing login verification on the pre-trusted client based on the remote login interface in the open state to obtain a target verification result, wherein the target verification result indicates whether the client is a trusted client. This invention solves the technical problem of low security protection for remote login to vehicles.

Description

Technical Field

[0001] This invention relates to the field of vehicles, and more specifically, to a method, apparatus, electronic device, and storage medium for verifying remote vehicle login. Background Technology

[0002] As automotive intelligence and connectivity continue to penetrate and become more widespread, the network risks exposed by intelligent connected vehicles are expanding, and relevant security regulations and standards are being introduced one after another. The network security of vehicles is becoming increasingly important. Among them, the Secure Shell (SSH) remote login service is an important function, and its security needs to be better guaranteed, and it needs to constantly adapt to new threats and attack methods.

[0003] One approach to protect the security of SSH remote login is to use a gateway device as a man-in-the-middle to perform pre-authentication with the SSH client. Another approach is to ensure the security of SSH remote login based on security list rules. However, both of these methods are relatively simple and have low security.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This invention provides a method, apparatus, electronic device, and storage medium for verifying remote vehicle login, in order to at least solve the technical problem of low security protection for remote vehicle login.

[0006] According to one aspect of the present invention, a method for verifying remote login to a vehicle is provided, comprising: after the vehicle's infotainment system is started, detecting a request access command sent by a client; in response to detecting the request access command, performing initial verification on the client based on the request access command to obtain an initial verification result, wherein the initial verification result is used to indicate whether the client is a pre-trusted client, and a pre-trusted client is used to indicate a client that has passed the initial verification but has not yet performed login verification; if the initial verification result indicates that the client is a pre-trusted client, controlling the remote login port of the infotainment system to change from a hidden state to an open state, wherein the hidden state indicates that the remote login interface is prohibited from being called, and the open state indicates that the remote login interface is allowed to be called; performing login verification on the pre-trusted client based on the remote login interface in the open state to obtain a target verification result, wherein the target verification result is used to indicate whether the client is a trusted client.

[0007] Optionally, the client is initially verified based on the request access command to obtain an initial verification result, including: performing initial verification on the request access command to obtain a verification sub-result, and recording the number of times the initial verification is performed on at least one request access command sent by the same client, wherein the verification sub-result is used to indicate whether the request access command meets the preset command rules; if the number of verifications is greater than or equal to the preset number of verifications, the initial verification result is determined to be that the client is not a pre-trusted client; if the verification sub-result is that the request access command meets the preset command rules and the number of verifications is less than the preset number of verifications, the initial verification result is determined to be that the client is a pre-trusted client.

[0008] Optionally, the preset instruction rules include a preset communication protocol and a preset tapping sequence. Initial verification of the access request instruction yields a verification sub-result, including: determining whether the communication protocol used by the access request instruction conforms to the preset communication protocol, thus obtaining a first verification sub-result; if the first verification sub-result indicates that the communication protocol conforms to the preset communication protocol, determining whether the tapping sequence in the access request instruction matches a preset tapping sequence, thus obtaining a second verification sub-result; if the second verification sub-result indicates that the tapping sequence matches the preset tapping sequence, determining that the access request instruction satisfies the preset instruction rules; if the first verification sub-result indicates that the communication protocol does not conform to the preset communication protocol, or if the second verification sub-result indicates that the tapping sequence does not match the preset tapping sequence, determining that the access request instruction does not satisfy the preset instruction rules.

[0009] Optionally, the initial verification of the client based on the request access command to obtain an initial verification result further includes: if the number of verifications is greater than or equal to a preset number of verifications, controlling the vehicle system to stop detecting the request access command and recording the stop time; comparing the stop time with a preset stop detection time to obtain a comparison result; if the comparison result shows that the stop time is less than the preset stop detection time, keeping the vehicle system stopped from executing the request access command sent by the client; and if the comparison result shows that the stop time is greater than or equal to the preset stop detection time, controlling the vehicle system to resume executing the request access command sent by the client.

[0010] Optionally, the method further includes: if the initial verification result indicates that the client is not a pre-trusted client, determining that the client is an untrusted client and controlling the remote login port to remain hidden, wherein the untrusted client is used to indicate a client that poses a security risk.

[0011] Optionally, login verification of the pre-trusted client is performed based on the remote login interface in the enabled state to obtain the target verification result, including: determining whether the Internet Protocol address of the pre-trusted client conforms to the preset firewall rules based on the remote login interface in the enabled state; if the Internet Protocol address conforms to the preset firewall rules, key verification is performed on the pre-trusted client to obtain the key verification result; if the key verification result is that the key verification is successful, the target verification result is determined to be that the client is a trusted client; if the Internet Protocol address does not conform to the preset firewall rules, or if the key verification result is that the key verification is unsuccessful, the verification result is determined to be that the client is an untrusted client.

[0012] Optionally, key verification is performed on the pre-trusted client to obtain a key verification result, including: encrypting a preset data sequence using a preset public key to obtain a first encryption result, and sending the first encryption result to the pre-trusted client; receiving a second encryption result sent by the pre-trusted client, wherein the second encryption result represents an encryption result obtained by the pre-trusted client decrypting the first encryption result using the private key corresponding to the preset public key, and encrypting the decrypted result using a preset encryption rule; encrypting the preset data sequence using the preset encryption rule to obtain a third encryption result; and determining a key verification result based on the second encryption result and the third encryption result.

[0013] Optionally, determining the key verification result based on the second encryption result and the third encryption result includes: comparing the second encryption result and the third encryption result to obtain a comparison result, wherein the comparison result is used to indicate whether the second encryption result and the third encryption result are consistent; if the comparison result shows that the second encryption result and the third encryption result are consistent, the key verification result is determined to be key verification passed; if the comparison result shows that the second encryption result and the third encryption result are inconsistent, the key verification result is determined to be key verification failed.

[0014] According to another aspect of the present invention, a vehicle remote login verification device is also provided, comprising: a detection module, configured to detect a request access command sent by a client after the vehicle infotainment system is started; a first verification module, configured to perform initial verification on the client based on the request access command in response to the detection of the request access command, and obtain an initial verification result, wherein the initial verification result is used to indicate whether the client is a pre-trusted client, and the pre-trusted client is used to indicate a client that has passed the initial verification but has not yet performed login verification; a conversion module, configured to control the remote login port of the vehicle infotainment system to change from a hidden state to an open state when the initial verification result indicates that the client is a pre-trusted client, wherein the hidden state indicates that the remote login interface is prohibited from being called, and the open state indicates that the remote login interface is allowed to be called; and a second verification module, configured to perform login verification on the pre-trusted client based on the remote login interface in the open state, and obtain a target verification result, wherein the target verification result is used to indicate whether the client is a trusted client.

[0015] According to another aspect of the present invention, an electronic device is also provided, characterized in that it includes: a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described vehicle remote login verification method when it runs.

[0016] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the storage medium is located to perform the above-described vehicle remote login verification method.

[0017] According to another aspect of the present invention, a computer program product is also provided, including a computer program that, when executed by a processor, implements the above-described vehicle remote login verification method.

[0018] In this embodiment of the invention, after the vehicle's infotainment system starts up, it detects access requests sent by clients. In response to the detected access requests, it performs initial verification on the client based on the access requests, obtaining an initial verification result. This initial verification result indicates whether the client is a pre-trusted client, meaning a client that has passed the initial verification but has not yet undergone login verification. If the initial verification result indicates the client is a pre-trusted client, the remote login port of the infotainment system is switched from a hidden state to an open state. The hidden state indicates that the remote login interface is prohibited from being called, while the open state indicates that the remote login interface is allowed to be called. Login verification is performed on the pre-trusted client based on the open remote login interface, obtaining a target verification result. This target verification result indicates whether the client is a trusted client, thus achieving vehicle remote login verification. It is noteworthy that this method performs initial verification on the client, only opens the remote login port of the infotainment system for clients that have passed verification, and performs login verification on pre-trusted clients that have passed the initial verification. This two-step verification combines a hidden and hardened security protection scheme, improving the security of vehicle remote login and thus solving the technical problem of low security protection for vehicle remote login. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0020] Figure 1 This is a flowchart of a vehicle remote login verification method according to an embodiment of the present invention;

[0021] Figure 2 This is a flowchart of an optional initial verification of a request access command according to an embodiment of the present invention;

[0022] Figure 3 This is a flowchart of an optional vehicle remote login verification method according to an embodiment of the present invention;

[0023] Figure 4 This is a schematic diagram of a vehicle remote login verification device according to an embodiment of the present invention. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] Example 1

[0027] According to an embodiment of the present invention, an embodiment of a method for verifying remote login of a vehicle is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0028] Figure 1 This is a flowchart of a vehicle remote login verification method according to an embodiment of the present invention, such as... Figure 1 As shown, the method includes the following steps:

[0029] Step S102: After the vehicle's infotainment system starts up, detect the access request command sent by the client.

[0030] The in-vehicle infotainment system mentioned in the above steps is an intelligent in-vehicle infotainment system that integrates multiple functions, typically including in-vehicle navigation, music playback, Bluetooth phone connectivity, voice recognition, and touchscreen control. This is the target system that the client needs to connect to. The client can connect to the in-vehicle infotainment system via SSH service, but the methods of connecting are not limited to this.

[0031] The access request instruction in the above steps is sent by the client to the vehicle system to request access to the vehicle system. The access request instruction contains a knock message sequence, which can be used to determine whether the client is trustworthy.

[0032] In one optional embodiment, after the vehicle's infotainment system starts up, a door-knocking service is configured within the system. Configuring the door-knocking service requires configuring the following: the type of access request instruction used as a door-knocking signal; for example, the access request instruction type can be configured as a Transmission Control Protocol (TCP) synchronization sequence number (SYN), but the configurable types are not limited to this; the port sequence that can open the remote login port of the infotainment system, i.e., the preset door-opening sequence; the knocking wait time; the wait time for multiple failed matches; the connection timeout wait time; and the command to be executed once the door-knocking message sequence sent by the client matches the preset door-opening sequence.

[0033] After configuring the door-knocking service, start the door-knocking service and hide the SSH service. The door-knocking service then begins detecting network request packets, i.e., access request commands, from the internet or the same Wi-Fi network. After the client sends an access request command to the vehicle's infotainment system server, the door-knocking service detects and retrieves the access request command sent by the client.

[0034] Step S104: In response to the detection of the access request instruction, the client is initially verified based on the access request instruction to obtain an initial verification result. The initial verification result is used to indicate whether the client is a pre-trusted client. A pre-trusted client is used to indicate a client that has passed the initial verification but has not yet performed login verification.

[0035] The initial verification result in the above steps can characterize the client's trustworthiness. If the initial verification result indicates that the client is a pre-trusted client, the client can proceed to the next login verification step. If the initial verification result indicates that the client is not a pre-trusted client, the client is not allowed to access the vehicle system this time.

[0036] The pre-trusted client in the above steps indicates that the client has a certain degree of trustworthiness, but is not completely trustworthy. That is, the pre-trusted client has the opportunity to access the vehicle's infotainment system, but further login verification is required. The pre-trusted client can access the vehicle's infotainment system after successful login verification.

[0037] In one optional example, after a request for access is detected, the door knocking service in the vehicle system obtains the type of the request for access. If the type of the request for access is the same as the type of the request for access configured when the door knocking service is configured, it continues to obtain the door knocking message sequence contained in the request for access. If they are different, the client's access request is directly rejected.

[0038] The knock message sequence contained in the access request command is compared with the preset door opening sequence configured when configuring the knock service. If they are completely consistent, the initial verification result is that the client is a pre-trusted client. If there is a discrepancy, the initial verification result is that the client is not a pre-trusted client.

[0039] Step S106: If the initial verification result indicates that the client is a pre-trusted client, the remote login port of the vehicle system is changed from a hidden state to an open state. The hidden state indicates that the remote login interface is prohibited from being called, and the open state indicates that the remote login interface is allowed to be called.

[0040] The remote login port of the vehicle infotainment system mentioned in the above steps refers to the network port used for remote access and control of the vehicle infotainment system. It can be an SSH service port, using the SSH protocol for remote login, or other types of ports, using other security protocols for remote login.

[0041] The hidden state in the above steps is used to indicate that remote access to the remote login port of the vehicle system is prohibited.

[0042] The "open" status in the above steps indicates that remote access to the vehicle's infotainment system's remote login port is permitted.

[0043] In one optional embodiment, if the initial verification result indicates that the client is a pre-trusted client, the SSH service port is opened, meaning the hidden remote login port of the vehicle infotainment system is turned on. If the initial verification result indicates that the client is not a pre-trusted client, the SSH service port remains in a "closed" state, meaning the remote login port of the vehicle infotainment system remains hidden and cannot be accessed externally. In this case, the door-knocking service in the vehicle infotainment system can still return a door-knocking failure message to the client, reminding the client to resend the access request command to knock on the door.

[0044] Step S108: Login verification is performed on the pre-trusted client based on the remote login interface in the enabled state to obtain the target verification result, wherein the target verification result is used to indicate whether the client is a trusted client.

[0045] The target verification result in the above steps can indicate whether the client is a trusted client. If the target verification result indicates that the client is a trusted client, the client can successfully connect to the vehicle system. If the target verification result indicates that the client is not a trusted client, the client's connection to the vehicle system will be rejected.

[0046] In one optional embodiment, when the remote login interface is enabled, login verification is performed on the pre-trusted client. Login verification employs a key-based authentication method. The remote login interface can pre-set login credential information and a shared key used to encrypt the login credential information. The pre-trusted client needs to provide encrypted login credential information upon login. The remote login interface verifies the information provided by the client. During verification, the preset shared key is used to decrypt the encrypted login credential information provided by the client. Then, the remote login interface compares the decrypted information with the previously preset login credential information. If they match, the target verification result is that the client is a trusted client; otherwise, the target verification result is that the client is not a trusted client.

[0047] By using key-based authentication to verify the login of pre-trusted clients, man-in-the-middle attacks can be avoided, ensuring the security of the client's connection to the vehicle's infotainment system.

[0048] In this embodiment of the invention, after the vehicle's infotainment system starts up, it detects access requests sent by clients. In response to the detected access requests, it performs initial verification on the client based on the access requests, obtaining an initial verification result. This initial verification result indicates whether the client is a pre-trusted client, meaning a client that has passed the initial verification but has not yet undergone login verification. If the initial verification result indicates the client is a pre-trusted client, the remote login port of the infotainment system is switched from a hidden state to an open state. The hidden state indicates that the remote login interface is prohibited from being called, while the open state indicates that the remote login interface is allowed to be called. Login verification is performed on the pre-trusted client based on the open remote login interface, obtaining a target verification result. This target verification result indicates whether the client is a trusted client, thus achieving vehicle remote login verification. It is noteworthy that this method performs initial verification on the client, only opens the remote login port of the infotainment system for clients that have passed verification, and performs login verification on pre-trusted clients that have passed the initial verification. This two-step verification combines a hidden and hardened security protection scheme, improving the security of vehicle remote login and thus solving the technical problem of low security protection for vehicle remote login.

[0049] Optionally, the client is initially verified based on the request access command to obtain an initial verification result, including: performing initial verification on the request access command to obtain a verification sub-result, and recording the number of times the initial verification is performed on at least one request access command sent by the same client, wherein the verification sub-result is used to indicate whether the request access command meets the preset command rules; if the number of verifications is greater than or equal to the preset number of verifications, the initial verification result is determined to be that the client is not a pre-trusted client; if the verification sub-result is that the request access command meets the preset command rules and the number of verifications is less than the preset number of verifications, the initial verification result is determined to be that the client is a pre-trusted client.

[0050] The preset instruction rules in the above steps are pre-set instruction rules. By judging whether the client's request access instruction meets the preset instruction rules, the client's verification sub-result can be determined.

[0051] The verification sub-result in the above steps is the result of verifying whether the request access instruction meets the preset instruction rules during the initial verification of the request access instruction, and can be used to determine the initial verification result.

[0052] The preset number of verification attempts in the above steps is a pre-set number of attempts used to compare with the number of initial verification attempts made by at least one request access command sent by the same client, thereby determining the initial verification result. It can be 3 times or 5 times, but is not limited to this, and can be preset according to the actual application situation.

[0053] In one optional embodiment, preset instruction rules are constructed. These rules can be built based on theoretical knowledge or practical application scenarios. The preset instruction rules can be configured to meet requirements regarding the tapping protocol and sequence rules, but their content is not limited to this. The client's request access instructions are then analyzed to determine whether they conform to the preset instruction rules, thereby determining the verification sub-result.

[0054] In addition, it is necessary to record the number of times that at least one access request sent by the same client undergoes initial verification within the knock-wait time. It should be noted that the knock-wait time can be preset when configuring the door-knocking service. The preset number of verifications is set to 5. However, this value is only an example, and the actual selectable value is not limited to this.

[0055] Figure 2 This is a flowchart of an optional initial verification of a request access command according to an embodiment of the present invention, and a process for determining the initial verification result based on the verification sub-result and the number of verifications is as follows: Figure 2As shown, after the client sends an access request, it checks whether the number of verification failures within the knocking wait time is greater than or equal to five. Since the client will not continue with initial verification after a successful initial verification, but will continue after a failed initial verification, checking whether the number of verification failures within the knocking wait time is greater than or equal to five is equivalent to checking whether the number of verification failures within the knocking wait time is greater than or equal to the preset number of verifications. If yes, the initial verification result is determined to be that the client is not a pre-trusted client, and due to the excessive number of failures, the client's access request is blocked during the multiple matching failure time, preventing the client from continuing to knock. It should be noted that the multiple matching failure time can be preset when configuring the knocking service. If no, it continues to check whether the knocking protocol and order rules meet the requirements, that is, whether the verification sub-result is that the access request meets the preset command rules. If yes, the initial verification result is determined to be that the client is a pre-trusted client, and the remote login port is opened; if no, the client can resend the access request and repeat the entire initial verification process.

[0056] Optionally, the preset instruction rules include a preset communication protocol and a preset tapping sequence. Initial verification of the access request instruction yields a verification sub-result, including: determining whether the communication protocol used by the access request instruction conforms to the preset communication protocol, thus obtaining a first verification sub-result; if the first verification sub-result indicates that the communication protocol conforms to the preset communication protocol, determining whether the tapping sequence in the access request instruction matches a preset tapping sequence, thus obtaining a second verification sub-result; if the second verification sub-result indicates that the tapping sequence matches the preset tapping sequence, determining that the access request instruction satisfies the preset instruction rules; if the first verification sub-result indicates that the communication protocol does not conform to the preset communication protocol, or if the second verification sub-result indicates that the tapping sequence does not match the preset tapping sequence, determining that the access request instruction does not satisfy the preset instruction rules.

[0057] The communication protocol mentioned above is a series of conventions that define data format, transmission rate, error detection and correction in data communication, which can ensure that different devices or systems can communicate effectively.

[0058] The preset communication protocol in the above steps is the communication protocol configured when configuring the knock service. You can choose Transmission Control Protocol / Internet Protocol (TCP / IP), Hypertext Transfer Protocol (HTTP), or File Transfer Protocol (FTP), but it is not limited to these.

[0059] The first verification sub-result in the above steps is the result of verifying whether the communication protocol used by the request access command issued by the client conforms to the preset communication protocol during the initial verification of the client, and can be used to determine the verification sub-result.

[0060] The knocking sequence in the above steps is a message sequence used for initial verification contained in the access request command.

[0061] The preset knocking sequence in the above steps is the knocking sequence configured when configuring the knocking service. For example, the preset knocking sequence can be set to "63621:tcp,59472:tcp,63621:tcp", but the above example is only an example, and the actual preset knocking sequence is not limited to this.

[0062] The second verification sub-result in the above steps is the result of verifying whether the tapping sequence in the request access command issued by the client conforms to the preset tapping sequence during the initial verification of the client, and can be used to determine the verification sub-result.

[0063] In one optional embodiment, a preset communication protocol can be configured when configuring the door-knocking service. This preset protocol can be set to require knocking once consecutively through ports 31023, 59472, and 31023 via TCP, and to accept only SYN handshake packets from TCP as the door-knocking signal. However, the specific content of the preset communication protocol is not limited to this. Simultaneously, a preset knocking sequence can be configured when configuring the door-knocking service, such as "63621:tcp,59472:tcp,63621:tcp". However, the specific content of the preset knocking sequence is not limited to this.

[0064] Upon receiving an access request, if the communication protocol used by the access request conforms to the preset communication protocol, the first verification result is that the communication protocol conforms to the preset communication protocol, and the verification of the tap sequence can be performed. If the communication protocol used by the access request does not conform to the preset communication protocol, the client's connection request can be directly rejected, and the remote login port will not be opened.

[0065] If the first verification sub-result indicates that the communication protocol conforms to the preset communication protocol, the message sequence used for initial verification, i.e., the tap sequence, is extracted from the access request instruction. The tap sequence is then compared with the preset tap sequence to determine the second verification sub-result. If the second verification sub-result is that the tap sequence matches the preset tap sequence, the verification sub-result indicates that the access request instruction meets the preset instruction rules; otherwise, the verification sub-result indicates that the access request instruction does not meet the preset instruction rules.

[0066] Optionally, the initial verification of the client based on the request access command to obtain an initial verification result further includes: if the number of verifications is greater than or equal to a preset number of verifications, controlling the vehicle system to stop detecting the request access command and recording the stop time; comparing the stop time with a preset stop detection time to obtain a comparison result; if the comparison result shows that the stop time is less than the preset stop detection time, keeping the vehicle system stopped from executing the request access command sent by the client; and if the comparison result shows that the stop time is greater than or equal to the preset stop detection time, controlling the vehicle system to resume executing the request access command sent by the client.

[0067] The stop time in the above steps is the time period from when the vehicle system stops detecting access request commands to the current time.

[0068] The preset stop detection time in the above steps is a pre-set time period used to compare with the stop time to obtain the comparison result. The preset stop detection time can be configured when configuring the door-knocking service. The preset stop detection time can be 1 hour, 20 minutes, or more, but is not limited to these. Other specific values ​​can be set according to the actual application requirements.

[0069] The comparison results described above are used to describe the relationship between the stop time and the preset stop time, and to determine whether the vehicle system should continue to stop detecting the client's request access command or resume detecting the client's request access command.

[0070] In one optional embodiment, if the number of verifications is greater than or equal to the preset number of verifications within a short period of time, it indicates that the number of client connection failures is too frequent, and the vehicle system is at risk of malicious attacks. Therefore, it is necessary to control the vehicle system to temporarily stop detecting access requests and not accept any client connections, thereby protecting its own security.

[0071] However, if the vehicle system indefinitely stops detecting access requests, while ensuring its own security, it will greatly reduce the user experience. Therefore, it is necessary to preset the stop time for detection and compare it with the actual stop time to determine the time when the vehicle system resumes detecting access requests.

[0072] When configuring the door-knocking service, the preset stop detection time is set to 10 minutes. However, this value is only an example, and the actual selectable preset stop detection time is not limited to this. The system determines the moment when the access request to stop is initiated and records the time from that moment to the current moment, i.e., the stop time. The stop time is compared with the preset stop detection time. If the stop time is less than the preset stop detection time, the vehicle system maintains the state of stopping the access request; if the stop time is greater than the preset stop detection time, the vehicle system resumes detecting client access requests.

[0073] Optionally, the method further includes: if the initial verification result indicates that the client is not a pre-trusted client, determining that the client is an untrusted client and controlling the remote login port to remain hidden, wherein the untrusted client is used to indicate a client that poses a security risk.

[0074] The untrusted clients mentioned above are those that failed the initial verification and pose a security risk.

[0075] In one optional embodiment, if the initial verification result indicates that the client is not a pre-trusted client, it means that the client failed the initial verification. In this case, the remote login port remains hidden and is not opened to the client. Furthermore, it is necessary to determine that the client is an untrusted client and record it in the untrusted client list.

[0076] Remote access permissions for untrusted clients on the untrusted client list can be restricted to reduce security risks. Restrictions can range from prohibiting untrusted clients from accessing the vehicle's infotainment system to requiring additional authentication steps, but are not limited to these measures. By restricting untrusted clients, the vehicle's infotainment system can better protect itself from potential security threats.

[0077] Optionally, login verification of the pre-trusted client is performed based on the remote login interface in the enabled state to obtain the target verification result, including: determining whether the Internet Protocol address of the pre-trusted client conforms to the preset firewall rules based on the remote login interface in the enabled state; if the Internet Protocol address conforms to the preset firewall rules, key verification is performed on the pre-trusted client to obtain the key verification result; if the key verification result is that the key verification is successful, the target verification result is determined to be that the client is a trusted client; if the Internet Protocol address does not conform to the preset firewall rules, or if the key verification result is that the key verification is unsuccessful, the verification result is determined to be that the client is an untrusted client.

[0078] The Internet Protocol address mentioned above refers to the address that uniquely identifies a device on the Internet, and is usually represented by an Internet Protocol (IP) address.

[0079] The firewall rules mentioned in the above steps refer to the rules set in a network security firewall, used to control the entry and exit of network traffic and restrict the methods and scope of network communication. Firewall rules can filter and restrict traffic based on information such as source IP address, destination IP address, and port number to protect network security.

[0080] The key verification result in the above steps is the result obtained after key verification of the pre-trusted client. It can characterize whether the pre-trusted client has passed the key verification and is used to determine whether the pre-trusted client is a trusted client.

[0081] In one optional embodiment, when the remote login interface is enabled, it is determined whether the Internet Protocol address (IP address) of the pre-trusted client conforms to preset firewall rules. When determining whether the pre-trusted client's IP address conforms to the preset firewall rules, the request header of the network packet in the access request instruction issued by the pre-trusted client is analyzed, and the IP address of the pre-trusted client is read. If the client IP address matches the firewall's dangerous list rules or does not match the safe list rules, i.e., the IP address does not conform to the preset firewall rules, the SSH service login authentication process is terminated, i.e., the client's connection to the vehicle system is terminated. The pre-trusted client is then determined to be an untrusted client and added to the untrusted client list.

[0082] If the Internet Protocol address conforms to the preset firewall rules, key verification continues for the pre-trusted client. Key verification can be performed using symmetric keys, public and private keys, or digital signatures, but the methods are not limited to these. If the key verification passes, the pre-trusted client is designated as a trusted client, and a connection is established between the client and the vehicle's infotainment system. If the key verification fails, the pre-trusted client is designated as an untrusted client, added to the untrusted client list, and the connection between the client and the vehicle's infotainment system is terminated.

[0083] Optionally, key verification is performed on the pre-trusted client to obtain a key verification result, including: encrypting a preset data sequence using a preset public key to obtain a first encryption result, and sending the first encryption result to the pre-trusted client; receiving a second encryption result sent by the pre-trusted client, wherein the second encryption result represents an encryption result obtained by the pre-trusted client decrypting the first encryption result using the private key corresponding to the preset public key, and encrypting the decrypted result using a preset encryption rule; encrypting the preset data sequence using the preset encryption rule to obtain a third encryption result; and determining a key verification result based on the second encryption result and the third encryption result.

[0084] The preset public key in the above steps is the pre-configured public key of the vehicle's infotainment system. The public key is used to encrypt data and can be made public to others. Anyone can use the public key to encrypt data, but only the holder of the private key can decrypt data encrypted with the public key.

[0085] The preset data sequence in the above steps is a pre-set data sequence, and random numbers generated by the server can be used as the preset data sequence.

[0086] The first encryption result in the above steps is obtained by the vehicle system encrypting the preset data sequence using the vehicle system's public key.

[0087] The private key corresponding to the preset public key in the above steps is the key used to decrypt data. It must be kept secret and can only be used by the key holder. The private key corresponding to the preset public key can be used to decrypt data encrypted with the preset public key, ensuring that only the designated recipient can decrypt and view the data.

[0088] The second encryption result in the above steps is that the pre-trusted client decrypts the first encryption result using the private key corresponding to the preset public key, and then encrypts the decrypted result again using the pre-encryption rules to obtain the encrypted result, which can be used to determine the key verification result.

[0089] The preset encryption rules in the above steps are pre-set encryption rules. The pre-trusted client uses the preset encryption rules to encrypt the content after decrypting the first encryption result to obtain the second encryption result. The vehicle system uses the preset encryption rules to encrypt the preset data sequence to obtain the third encryption result.

[0090] The third encryption result in the above steps is the result obtained by the vehicle system encrypting the preset data sequence using preset encryption rules, and can be used to determine the key verification result.

[0091] The key verification result in the above steps is used to characterize whether the pre-trusted client has passed the key verification, and can determine whether the pre-trusted client is a trusted client.

[0092] In one optional embodiment, a trusted public key key_1, also known as a preset public key, is pre-configured in the vehicle system. At the same time, the vehicle system generates a random number r_1, also known as a preset data sequence, and encrypts the random number r_1 with the trusted public key key_1 to obtain a first encryption result. The first encryption result is then sent to the pre-trusted client.

[0093] After receiving the first encryption result, the pre-trusted client decrypts the first encryption result using the private key key_2 corresponding to the preset public key to obtain a random number r_1. Then, according to the preset encryption rules, r_1 and the timestamp t_1 are merged into a sequence st_1, which is then encrypted using a secure hash algorithm to obtain a digest hash_1. The digest hash_1 is also the second encryption result.

[0094] The timestamp t_1 and hash_1 are sent to the vehicle system. The vehicle system, according to the preset encryption rules, merges the random number r_1 and the timestamp t_1 obtained from the pre-trusted client into a sequence st_2. It also uses a secure hash algorithm to encrypt st_2 and generate hash_2, which is the third encryption result.

[0095] The second and third encryption results are compared to determine the key verification result.

[0096] Optionally, determining the key verification result based on the second encryption result and the third encryption result includes: comparing the second encryption result and the third encryption result to obtain a comparison result, wherein the comparison result is used to indicate whether the second encryption result and the third encryption result are consistent; if the comparison result shows that the second encryption result and the third encryption result are consistent, the key verification result is determined to be key verification passed; if the comparison result shows that the second encryption result and the third encryption result are inconsistent, the key verification result is determined to be key verification failed.

[0097] The key verification result in the above steps is obtained by comparing the second encryption result and the third encryption result, and is used to characterize whether the second encryption result and the third encryption result are consistent.

[0098] In one alternative embodiment, key verification is a process of confirming the integrity and security of data. During key verification, the data is typically encrypted, generating different encryption results, which are then compared to verify the validity of the key. When comparing the second and third encryption results, each part needs to be compared individually to ensure consistency. If the two encryption results are identical, the key verification is considered successful; if any of the two encryption results differ, the key verification fails.

[0099] The following description uses a preferred embodiment. Figure 3 This is a flowchart of an optional vehicle remote login verification method according to an embodiment of the present invention, such as... Figure 3 As shown, on the vehicle infotainment system side, after the system is powered on, it first performs door knock configuration, then initiates door knock service detection. Upon detecting a door knock request from the client (i.e., the access request command mentioned above), it checks whether the handshake protocol conforms to the rules. If not, it checks whether the client has failed to knock 5 times within the knock waiting time. If so, it continues to check whether the knock sequence conforms to the rules. If the knock sequence does not conform to the rules, it also needs to check whether the client has failed to knock 5 times within the knock waiting time. It should be noted that the 5 times mentioned here is only an example value; the actual value that can be set is not limited to 5 times and can be set according to the actual application.

[0100] If a client fails to knock 5 times within the knocking wait time, the knocking service will close the detection during the multiple failed match waiting period and determine if the stop detection time has expired. If the stop detection time has expired, the client can send a knock request again, and the knock request can continue to be detected by the knocking service. If the stop detection time has not expired, the knocking service will remain in the closed detection state. If the client fails to knock 5 times within the knocking wait time, the client can send a knock request again, and the knock request can continue to be detected by the knocking service.

[0101] If the tap sequence matches the rules, the vehicle system initiates a Secure Shell Protocol (SEP) service check and determines whether the client's internet address matches the security list rules. If not, the connection fails; otherwise, the key verification phase continues. During key verification, a random number is generated, encrypted with the public key to generate digest 1, and sent to the client. The client receives digest 1, decrypts it with its private key to obtain the random number, and calculates digest 2 using the random number and a timestamp, then sends it to the vehicle system. The vehicle system receives digest 2 and the timestamp and calculates digest 3 in the same way. Then, it checks if digest 2 and digest 3 match. If they match, authentication succeeds; otherwise, authentication fails.

[0102] Example 2

[0103] According to an embodiment of the present invention, an embodiment of a vehicle remote login verification device is provided. The device can execute the vehicle remote login verification method provided in Embodiment 1 above. The specific implementation method and preferred application scenario are the same as those in Embodiment 1 above, and will not be repeated here.

[0104] Figure 4 This is a schematic diagram of a vehicle remote login verification device according to an embodiment of the present invention, as shown below. Figure 4 As shown:

[0105] The detection module 40 is used to detect the access request command sent by the client after the vehicle's infotainment system is started.

[0106] The first verification module 42 is used to respond to the detection of a request access command, perform initial verification on the client based on the request access command, and obtain an initial verification result. The initial verification result is used to indicate whether the client is a pre-trusted client. A pre-trusted client is used to indicate a client that has passed the initial verification but has not yet performed login verification.

[0107] The conversion module 44 is used to control the remote login port of the vehicle system to change from a hidden state to an open state when the initial verification result is that the client is a pre-trusted client. The hidden state is used to indicate that the remote login interface is prohibited from being called, and the open state is used to indicate that the remote login interface is allowed to be called.

[0108] The second verification module 46 is used to perform login verification on the pre-trusted client based on the remote login interface in the enabled state, and obtain the target verification result, wherein the target verification result is used to indicate whether the client is a trusted client.

[0109] Optionally, the first verification module includes: a first verification unit, configured to perform initial verification on the request access command, obtain a verification sub-result, and record the number of times the initial verification is performed on at least one request access command sent by the same client, wherein the verification sub-result is used to indicate whether the request access command meets the preset command rules; a first determining unit, configured to determine that the initial verification result is that the client is not a pre-trusted client if the number of verifications is greater than or equal to the preset number of verifications; and a second determining unit, configured to determine that the initial verification result is that the client is a pre-trusted client if the verification sub-result is that the request access command meets the preset command rules and the number of verifications is less than the preset number of verifications.

[0110] Optionally, the first verification unit is further configured to determine whether the communication protocol used by the request access instruction conforms to a preset communication protocol, thereby obtaining a first verification sub-result; if the first verification sub-result indicates that the communication protocol conforms to the preset communication protocol, it determines whether the tapping sequence in the request access instruction matches a preset tapping sequence, thereby obtaining a second verification sub-result; if the second verification sub-result indicates that the tapping sequence matches the preset tapping sequence, it determines that the verification sub-result satisfies the preset instruction rule; if the first verification sub-result indicates that the communication protocol does not conform to the preset communication protocol, or if the second verification sub-result indicates that the tapping sequence does not match the preset tapping sequence, it determines that the verification sub-result does not satisfy the preset instruction rule.

[0111] Optionally, the first verification unit is further configured to control the vehicle system to stop detecting the request access instruction and record the stop time when the number of verifications is greater than or equal to the preset number of verifications; compare the stop time with the preset stop detection time to obtain a comparison result; keep the vehicle system from executing the request access instruction sent by the detection client when the comparison result is that the stop time is less than the preset stop detection time; and control the vehicle system to resume executing the request access instruction sent by the detection client when the comparison result is that the stop time is greater than or equal to the preset stop detection time.

[0112] Optionally, the first verification module is further configured to determine that the client is an untrusted client if the initial verification result indicates that the client is not a pre-trusted client, and to control the remote login port to remain hidden, wherein the untrusted client is used to indicate a client that poses a security risk.

[0113] Optionally, the second verification module includes: a judgment unit, used to judge whether the Internet Protocol address of the pre-trusted client conforms to preset firewall rules based on the remote login interface in the enabled state; a second verification unit, used to perform key verification on the pre-trusted client and obtain a key verification result if the Internet Protocol address conforms to the preset firewall rules; a third determination unit, used to determine that the target verification result is a trusted client if the key verification result is successful; and a fourth determination unit, used to determine that the verification result is an untrusted client if the Internet Protocol address does not conform to the preset firewall rules or the key verification result is unsuccessful.

[0114] Optionally, the second verification unit is further configured to encrypt a preset data sequence using a preset public key to obtain a first encryption result, and send the first encryption result to a pre-trusted client; receive a second encryption result sent by the pre-trusted client, wherein the second encryption result represents an encryption result obtained by the pre-trusted client decrypting the first encryption result using the private key corresponding to the preset public key and encrypting the decryption result using a preset encryption rule; encrypt the preset data sequence using the preset encryption rule to obtain a third encryption result; and determine a key verification result based on the second encryption result and the third encryption result.

[0115] Optionally, the second verification unit is further configured to compare the second encryption result and the third encryption result to obtain a comparison result, wherein the comparison result is used to indicate whether the second encryption result and the third encryption result are consistent; if the comparison result shows that the second encryption result and the third encryption result are consistent, the key verification result is determined to be key verification passed; if the comparison result shows that the second encryption result and the third encryption result are inconsistent, the key verification result is determined to be key verification failed.

[0116] Example 3

[0117] According to an embodiment of the present invention, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the vehicle remote login verification method in Embodiment 1 when it runs.

[0118] Example 4

[0119] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to execute the vehicle remote login verification method of various embodiments of the present invention.

[0120] Example 5

[0121] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the vehicle remote login verification method in various embodiments of the present invention.

[0122] Example 6

[0123] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program, which, when executed by a processor, implements the vehicle remote login verification method in various embodiments of the present invention.

[0124] 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.

[0125] In the above embodiments of the present invention, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0127] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

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

[0129] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0130] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for verifying remote vehicle login, characterized in that, include: After the vehicle's infotainment system starts up, it detects the access request sent by the client. In response to detecting the access request instruction, the client is initially verified based on the access request instruction to obtain an initial verification result, wherein the initial verification result is used to indicate whether the client is a pre-trusted client, and the pre-trusted client is used to indicate a client that has passed the initial verification but has not yet performed login verification; If the initial verification result indicates that the client is the pre-trusted client, the remote login port of the vehicle system is controlled to change from a hidden state to an open state. The hidden state indicates that the remote login port is prohibited from being called, and the open state indicates that the remote login port is allowed to be called. Login verification is performed on the pre-trusted client based on the remote login port in the open state to obtain a target verification result, wherein the target verification result is used to indicate whether the client is a trusted client; The initial verification of the client based on the requested access instruction, and the resulting initial verification result, include: The request access command is initially verified to obtain a verification sub-result, and the number of verifications performed on at least one request access command sent by the same client is recorded. The verification sub-result is used to indicate whether the request access command meets the preset command rules. If the number of verification attempts is greater than or equal to the preset number of verification attempts, the initial verification result is determined to be that the client is not the pre-trusted client. If the verification sub-result indicates that the requested access instruction satisfies the preset instruction rule and the number of verifications is less than the preset number of verifications, then the initial verification result is determined to be that the client is the pre-trusted client. The preset instruction rules include a preset communication protocol and a preset tap sequence, which perform initial verification on the request access instruction to obtain a verification sub-result, including: Determine whether the communication protocol used by the requested access instruction conforms to the preset communication protocol to obtain the first verification sub-result; If the first verification sub-result indicates that the communication protocol conforms to the preset communication protocol, determine whether the tapping sequence in the request access instruction matches the preset tapping sequence to obtain the second verification sub-result. If the second verification sub-result is that the tapping sequence matches the preset tapping sequence, then the verification sub-result is determined to be that the request access instruction satisfies the preset instruction rule; If the first verification sub-result indicates that the communication protocol does not conform to the preset communication protocol, or if the second verification sub-result indicates that the tapping sequence does not match the preset tapping sequence, then the verification sub-result is determined to be that the request access instruction does not satisfy the preset instruction rule.

2. The vehicle remote login verification method according to claim 1, characterized in that, The method further includes: If the number of verifications is greater than or equal to the preset number of verifications, the vehicle system is controlled to stop detecting the request access command and the stop time is recorded. The comparison result is obtained by comparing the stop time with the preset stop detection time; If the comparison result shows that the stopping time is less than the preset stopping detection time, the vehicle system continues to stop executing the request access command sent by the detection client. If the comparison result indicates that the stop time is greater than or equal to the preset stop detection time, the vehicle system is controlled to resume executing the request access command sent by the detection client.

3. The vehicle remote login verification method according to claim 1, characterized in that, The method further includes: If the initial verification result indicates that the client is not a pre-trusted client, the client is determined to be an untrusted client, and the remote login port is kept hidden. The untrusted client is used to indicate a client that poses a security risk.

4. The vehicle remote login verification method according to claim 1, characterized in that, Login verification is performed on the pre-trusted client based on the remote login port in the open state to obtain the target verification result, including: Based on the remote login port in the open state, determine whether the Internet Protocol address of the pre-trusted client conforms to the preset firewall rules; If the Internet Protocol address conforms to the preset firewall rules, key verification is performed on the pre-trusted client to obtain the key verification result; If the key verification result is successful, the target verification result indicates that the client is the trusted client; If the Internet Protocol address does not conform to the preset firewall rules, or if the key verification result is that the key verification fails, the verification result is determined to be that the client is an untrusted client.

5. The vehicle remote login verification method according to claim 4, characterized in that, Perform key verification on the pre-trusted client to obtain the key verification result, including: A preset data sequence is encrypted using a preset public key to obtain a first encryption result, and the first encryption result is sent to the pre-trusted client; The system receives a second encryption result sent by the pre-trusted client, wherein the second encryption result represents an encryption result obtained by the pre-trusted client decrypting the first encryption result using the private key corresponding to the preset public key and encrypting the decrypted result using a preset encryption rule. The preset data sequence is encrypted using the preset encryption rule to obtain a third encryption result; The key verification result is determined based on the second encryption result and the third encryption result.

6. The vehicle remote login verification method according to claim 5, characterized in that, Determining the key verification result based on the second encryption result and the third encryption result includes: The second encryption result and the third encryption result are compared to obtain a comparison result, wherein the comparison result is used to indicate whether the second encryption result and the third encryption result are consistent; If the comparison result shows that the second encryption result and the third encryption result are consistent, the key verification result is determined to be key verification passed; If the comparison result shows that the second encryption result and the third encryption result are inconsistent, the key verification result is determined to be key verification failure.

7. A verification device for remote vehicle login, characterized in that, include: The detection module is used to detect access requests sent by the client after the vehicle's infotainment system starts up. The first verification module is configured to, in response to the detection of the request access instruction, perform initial verification on the client based on the request access instruction to obtain an initial verification result, wherein the initial verification result is used to indicate whether the client is a pre-trusted client, and the pre-trusted client is used to indicate a client that has passed the initial verification but has not yet performed login verification; The conversion module is used to control the remote login port of the vehicle system to change from a hidden state to an open state when the initial verification result is that the client is the pre-trusted client. The hidden state is used to indicate that the remote login port is prohibited from being called, and the open state is used to indicate that the remote login port is allowed to be called. The second verification module is used to perform login verification on the pre-trusted client based on the remote login port in the open state, and obtain a target verification result, wherein the target verification result is used to indicate whether the client is a trusted client; The first verification module is used to perform initial verification on the request access command, obtain a verification sub-result, and record the number of times the initial verification is performed on at least one request access command sent by the same client. The verification sub-result is used to indicate whether the request access command meets a preset command rule. If the number of verifications is greater than or equal to the preset number of verifications, the initial verification result is determined to be that the client is not the pre-trusted client. If the verification sub-result is that the request access command meets the preset command rule and the number of verifications is less than the preset number of verifications, the initial verification result is determined to be that the client is the pre-trusted client. The preset instruction rules include a preset communication protocol and a preset tapping sequence; the first verification module is further configured to determine whether the communication protocol used by the request access instruction conforms to the preset communication protocol, and obtain a first verification sub-result; if the first verification sub-result indicates that the communication protocol conforms to the preset communication protocol, the module determines whether the tapping sequence in the request access instruction matches the preset tapping sequence, and obtains a second verification sub-result; if the second verification sub-result indicates that the tapping sequence matches the preset tapping sequence, the module determines that the request access instruction satisfies the preset instruction rules; if the first verification sub-result indicates that the communication protocol does not conform to the preset communication protocol, or if the second verification sub-result indicates that the tapping sequence does not match the preset tapping sequence, the module determines that the request access instruction does not satisfy the preset instruction rules.

8. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program, when running, executes the vehicle remote login verification method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the storage medium is located to perform the vehicle remote login verification method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the vehicle remote login verification method according to any one of claims 1 to 6.

Images