Device access verification method, vehicle, electronic device, and computer storage medium

Abstract

The present application provides a device access verification method, a vehicle, an electronic device, and a computer storage medium. The method is applied to the vehicle; and comprises: receiving an authentication request of a device, wherein the authentication request comprises a protocol application time and a device certificate of the device, and the protocol application time is the time at which the device sends an application request to an online certificate status protocol (OCSP) server on the basis of an OCSP; acquiring an authentication verification time, the authentication verification time being a time determined on the basis of coordinated universal time; calculating a time difference between the authentication verification time and the protocol application time; detecting whether the time difference falls within a preset time difference range; if it is detected that the time difference falls within the preset time difference range, performing access verification on the device certificate; and if a result of the access verification is that the verification is successful, opening an access permission of the device to the vehicle. In the present application, when a vehicle or both the vehicle and a device are offline, the device can be subjected to identity authentication, thereby avoiding the problem of aftermarket diagnosis caused by the inability to perform identity authentication on the device.

Description

Access authentication methods for devices, vehicles, electronic devices, and computer storage media

[0001] This application claims priority to Chinese Patent Application No. 2024118092590, filed on December 10, 2024, entitled “Method for Access Verification of Device, Vehicle, Electronic Device and Computer Storage Medium”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to, but is not limited to, the field of vehicle technology, specifically to a device access verification method, a vehicle, an electronic device, and a computer storage medium. Background Technology

[0003] Currently, to prevent vehicle data leaks, devices must be authenticated before sending access requests to vehicles. Only after successful authentication are the devices granted the appropriate permissions to access the vehicle. For example, Online Certificate Status Protocol (OCSP) verification can be added to Public Key Infrastructure (PKI) certificate authentication to authenticate the device's identity.

[0004] However, identity authentication based on OCSP verification has a problem: when the vehicle is offline or there is a network failure in the area where the vehicle is located, and both the vehicle and the device are offline, the device cannot be authenticated, which can lead to problems in the aftermarket diagnosis. Summary of the Invention

[0005] In view of the above, embodiments of this application provide a device access verification method, a vehicle, an electronic device, and a computer storage medium, which can authenticate the device when the vehicle is offline or when both the vehicle and the device are offline, and grant the device the corresponding access permissions after the device is successfully authenticated, thereby ensuring the security of vehicle data and avoiding the problem of aftermarket diagnostics caused by the inability to authenticate the device.

[0006] The following is an overview of the subject matter described in detail herein. This overview is not intended to limit the scope of the claims.

[0007] This application provides a device access verification method applied to a vehicle. The method includes: receiving an authentication request from the device, the authentication request including a protocol request time and the device certificate, wherein the protocol request time is the time when the device sends the request to an Online Certificate Status Protocol (OCSP) server or the time when the device receives a response from the OCSP server; obtaining the authentication verification time when the device sends the authentication request, the authentication verification time being a time determined based on Coordinated Universal Time (UTC); calculating the time difference between the authentication verification time and the protocol request time; detecting whether the time difference is within a preset time difference range; if the time difference is detected to be within the preset time difference range, performing access verification on the device certificate; and if the access verification result is successful, granting the device access rights to the vehicle.

[0008] Compared with related technologies, the embodiments of this application have at least the following advantages: When a device sends an authentication request to a vehicle, device authentication is required to prevent vehicle data leakage. Based on the Online Certificate Status Protocol (OCSP), the time when the device sends the request to the OCSP server or the time when the device receives the response from the OCSP server is used as the protocol request time. Since this protocol request time is a fixed time, it is not affected by whether the vehicle is connected to the internet. This allows for authentication verification based on the protocol request time regardless of whether the vehicle is offline or both the vehicle and the device are offline. When the authentication verification time and the protocol request time, as well as the access verification of the device certificate, are both successful, the device's access to the vehicle is granted. By double-checking the relevant time in the device authentication and the device certificate, the security of vehicle data is further guaranteed, and the problem of aftermarket diagnostics caused by the inability to authenticate the device is avoided.

[0009] In some possible implementations, the authentication verification time includes Coordinated Universal Time (UTC); calculating the time difference between the authentication verification time and the protocol application time includes: calculating the difference between the UTC and the protocol application time, and using the difference between the UTC and the protocol application time as a first difference; detecting whether the time difference is within a preset time difference range includes: detecting whether the first difference is within the preset time difference range; and if the time difference is detected to be within the preset time difference range, performing access verification on the device certificate includes: if the first difference is detected to be within the preset time difference range, performing access verification on the device certificate.

[0010] In some possible implementations, the authentication verification time includes the in-vehicle local time, which is a time determined based on the Coordinated Universal Time (UTC) and the vehicle's location; calculating the time difference between the authentication verification time and the protocol application time includes: calculating the difference between the in-vehicle local time and the protocol application time, and using the difference between the in-vehicle local time and the protocol application time as a second difference; detecting whether the time difference is within a preset time difference range includes: detecting whether the second difference is within the preset time difference range; and if the time difference is detected to be within the preset time difference range, performing access verification on the device certificate includes: if the second difference is detected to be within the preset time difference range, performing access verification on the device certificate.

[0011] In some possible implementations, after detecting whether the second difference is within the preset time difference range, the method further includes: if the second difference is detected to be outside the preset time difference range, detecting whether the in-vehicle local time is earlier than the protocol application time; if the in-vehicle local time is detected to be earlier than the protocol application time, performing access verification on the device certificate.

[0012] In some possible implementations, the authentication verification time includes Coordinated Universal Time (UTC) and the vehicle's local time, where the vehicle's local time is determined based on the UTC and the vehicle's location. The time difference includes a first difference and a second difference. Calculating the time difference between the authentication verification time and the protocol application time includes: calculating the first difference between the UTC and the protocol application time and calculating the second difference between the vehicle's local time and the protocol application time. Detecting whether the time difference is within a preset time difference range and performing access verification on the device certificate includes: detecting whether the first difference is within the preset time difference range; if the first difference is not within the preset time difference range, detecting whether the second difference is within the preset time difference range; if the second difference is within the preset time difference range, performing access verification on the device certificate.

[0013] In some possible implementations, the step of verifying access to the device certificate if the time difference is detected to be within the preset time difference range further includes: if the second difference is detected to be within the preset time difference range, detecting whether the in-vehicle local time is earlier than the protocol application time; if the in-vehicle local time is detected to be earlier than the protocol application time, verifying access to the device certificate.

[0014] In some possible implementations, the application request includes status information requesting the device certificate.

[0015] In some possible implementations, the access verification of the device certificate includes: obtaining the OCSP detection time and the certificate validity period of the device certificate, wherein the OCSP detection time is the time between the protocol application time and the authentication verification time when the detection passes; detecting whether the OCSP detection time is within the certificate validity period; if the OCSP detection time is detected to be within the certificate validity period, determining that the device certificate is valid; if the OCSP detection time is detected to be outside the certificate validity period, determining that the device certificate is invalid.

[0016] In some possible implementations, the access verification of the device certificate includes: sending a challenge message to the device, the challenge message being configured to request the device to prove ownership of the device certificate, the challenge message including an authentication random number; receiving a signed response message from the device, the signed response message being calculated by the device using the device's private key on the authentication random number; verifying the signed response message based on the device's public key; and if the verification of the signed response message passes, determining that the device certificate is the device's digital certificate.

[0017] In some possible implementations, the access verification of the device certificate includes: receiving the parsing result of the device's response to the OCSP, wherein the OCSP response is information received by the device based on the OCSP protocol and the device certificate after being signed by the OCSP server, and the device is configured to parse the signed OCSP response to obtain the parsing result; if the parsing result is not revoked, the status of the device certificate is determined to be not revoked.

[0018] A second aspect of this application discloses a vehicle, comprising: a receiving module configured to receive an authentication request from a device, the authentication request including a protocol request time and the device certificate of the device, wherein the protocol request time is the time when the device sends the request to an Online Certificate Status Protocol (OCSP) server or the time when the device receives the OCSP server; an acquisition module configured to acquire the authentication verification time when the device issues the authentication request, the authentication verification time being a time determined based on Coordinated Universal Time (UTC); a calculation module configured to calculate the time difference between the authentication verification time and the protocol request time; a detection module configured to detect whether the time difference is within a preset time difference range; a verification module configured to perform access verification on the device certificate if the time difference is detected to be within the preset time difference range; and an access control module configured to grant the device access rights to the vehicle if the access verification result is successful.

[0019] A third aspect of this application discloses an electronic device, which includes a processor and a memory. The memory is configured to store instructions, and the processor is configured to invoke the instructions in the memory to cause the electronic device to execute the aforementioned device access verification method.

[0020] The fourth aspect of this application discloses a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the aforementioned device access verification method.

[0021] Understandably, the vehicle of the second aspect, the electronic device of the third aspect, and the computer storage medium of the fourth aspect all correspond to the method of the first aspect. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0022] After reading and understanding the accompanying diagrams and detailed descriptions, other aspects will become clear. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] Figure 1 is a schematic flowchart of a device access verification method according to an embodiment of this application;

[0025] Figure 2 is another flowchart illustrating a device access verification method according to an embodiment of this application;

[0026] Figure 3 is an interactive schematic diagram of a vehicle authenticating its identity with a device according to an embodiment of this application;

[0027] Figure 4 is another interactive schematic diagram of a vehicle authenticating its identity with a device according to an embodiment of this application;

[0028] Figure 5 is a structural schematic diagram of a vehicle according to an embodiment of this application;

[0029] Figure 6 is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present application.

[0030] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0031] To better understand the above-mentioned objectives, features, and advantages of this application, the application will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0032] The following description sets forth many specific details to provide a full understanding of this application. The described embodiments are only some, not all, of the embodiments of this application.

[0033] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein in the specification of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application.

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

[0035] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural.

[0036] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] Please refer to Figure 1, which is a flowchart illustrating the device access verification method provided in this embodiment of the application. This embodiment is applied to a vehicle. The vehicle can be a new energy vehicle, a fuel vehicle, etc., and this application does not limit the specific type of vehicle.

[0038] The device access verification method includes the following steps:

[0039] Step 101: Receive the device's authentication request, which includes the protocol application time and the device's certificate.

[0040] In this embodiment, the device certificate is a digital certificate applied for by the device from a Certificate Authority (CA). The device can be a diagnostic tool. For example, a diagnostic tool can be used to detect the location and cause of a vehicle malfunction. In other embodiments, the device can also be other devices besides a diagnostic tool, such as a fuel consumption analyzer, an ignition analyzer, etc.

[0041] Specifically, before sending an authentication request to the vehicle, the device checks if a usable digital certificate exists locally. If no usable digital certificate is detected, the device generates a public and private key pair, uploads the public key and certificate application information to the CA, and the CA sends a digital certificate to the device based on the public key and certificate application information.

[0042] After a device obtains a digital certificate from a Certificate Authority (CA), and when the device needs to access the vehicle, it sends a request to the CA's OCSP server based on the Online Certificate Status Protocol (OCSP) to obtain an OCSP response for the digital certificate. The OCSP server sends an OCSP response (which includes OCSP Stapling information, also known as OCSP binding information) to the device. The request includes a request for the status of the device's certificate, and the OCSP Stapling is used to query the status of the digital certificate. OCSP is an online query protocol used to verify the legitimacy of certificates. The OCSP response contains certificate status information, such as whether it has been revoked or is valid, thus verifying the certificate's validity. Therefore, when a device sends a request to the OCSP server, the OCSP Stapling information includes the status of the device's certificate.

[0043] In this embodiment, the protocol request time is the time when the device sends a request to the OCSP server or the time when the device receives a response from the OCSP server, based on the OCSP protocol. For example, the time when the device sends a request to the OCSP server is used as the protocol request time. In subsequent processes, when using the protocol request time to verify the device's identity, since the protocol request time is fixed, the device's identity can be verified regardless of whether the vehicle and device are connected to the network or disconnected, thus expanding the application scope of the verification.

[0044] Step 102: Obtain the authentication verification time when the device sends the authentication request. The authentication verification time is a time determined based on Coordinated Universal Time (UTC).

[0045] In one embodiment, the authentication verification time includes Coordinated Universal Time (UTC) and the vehicle's local time. UTC is also known as Coordinated Universal Time or Coordinated International Time. The vehicle's local time is determined based on UTC and the vehicle's location. In this embodiment, the vehicle's local time is maintained by a crystal oscillator within the vehicle. The crystal oscillator primarily uses a high-precision oscillation frequency to localize the vehicle's calculated time.

[0046] Specifically, the vehicle is equipped with a vehicle gateway module, a telematics module, and an in-vehicle local time module. The vehicle gateway module is communicatively connected to the telematics module and the in-vehicle local time module. The telematics module is configured to communicate with a cloud server and obtain Coordinated Universal Time (UTC) from the cloud server. A crystal oscillator is located within the in-vehicle local time module.

[0047] In some embodiments, the telematics module is further configured to send Coordinated Universal Time (UTC) to the in-vehicle local time module. Upon receiving the UTC, the in-vehicle local time module updates its local time based on the UTC. The vehicle gateway module is configured to receive both the UTC sent by the telematics module and the in-vehicle local time sent by the in-vehicle local time module, and authenticate the coordination request time based on either the UTC or the in-vehicle local time.

[0048] Step 103: Calculate the time difference between the authentication verification time and the protocol application time.

[0049] In one embodiment, when the authentication verification time includes Coordinated Universal Time (UTC) or in-vehicle local time, a first difference between UTC and the protocol request time is calculated. Alternatively, a second difference between the in-vehicle local time and the protocol request time is calculated.

[0050] In another embodiment, when the authentication verification time includes both Coordinated Universal Time (UTC) and in-vehicle local time, a first difference between UTC and protocol request time is calculated, and a second difference between in-vehicle local time and protocol request time is calculated.

[0051] Step 104: Check whether the time difference is within the preset time difference range.

[0052] The preset time difference range includes a first preset difference range and a second preset difference range.

[0053] In one embodiment, when the authentication verification time includes Coordinated Universal Time (UTC) or in-vehicle local time, a first difference is detected as being within a first preset difference range. Alternatively, a second difference is detected as being within a second preset difference range.

[0054] In another embodiment, when the authentication verification time includes the world standard time and the vehicle's local time, the system detects whether the first difference is within a first preset difference range and whether the second difference is within a second preset difference range.

[0055] The first preset difference range and the second preset difference range can be the same or different.

[0056] For example, the first preset difference range can be set to [-8,8], the second preset difference range can also be set to [-8,8], or the second preset difference range can be set to [-10,10].

[0057] Step 105: If the detected time difference is within the preset time difference range, perform access verification on the device certificate.

[0058] In one embodiment, when the authentication verification time includes Coordinated Universal Time (UTC) or the vehicle's local time, if a first difference is detected within a first preset difference range, access verification of the device certificate is performed. Alternatively, if a second difference is detected within a second preset difference range, access verification of the device certificate is performed.

[0059] In another embodiment, when the authentication verification time includes the world standard time and the vehicle's local time, if the first difference is detected to be outside the first preset difference range, then the second difference is detected to be within the second preset difference range. If the second difference is detected to be within the second preset difference range, the device certificate is access verified.

[0060] In another embodiment, when the authentication verification time includes the world standard time and the vehicle's local time, the system first checks whether the second difference is within the second preset difference range. If the second difference is not within the second preset difference range, the system then checks whether the first difference is within the first preset difference range. If the first difference is within the first preset difference range, the system performs access verification on the device certificate.

[0061] If the detected time difference is within the preset time difference range, it indicates that the interval between the device sending the request to the OCSP server and the authentication verification time is short, and access verification of the device certificate can be performed. Conversely, if the interval is long, it indicates that the OCSP Stapling information may be invalid. Therefore, authentication of the protocol request time fails.

[0062] Furthermore, when the authentication verification time includes the vehicle's local time, if the second difference is detected to be outside the second preset difference range, it checks whether the vehicle's local time is earlier than the protocol application time. If the vehicle's local time is detected to be earlier than the protocol application time, access verification of the device certificate is performed.

[0063] If the second difference is detected to be outside the second preset difference range, the system checks whether the in-vehicle local time is earlier than the protocol request time to determine if time rollback has occurred. If the in-vehicle local time is detected to be earlier than the protocol request time, it indicates a significant time rollback. Therefore, to avoid errors in the in-vehicle local time due to damage to the in-vehicle local time module, which could prevent verification and affect device access to the vehicle, the check between the in-vehicle local time and the protocol request time is skipped, and the device certificate is directly verified. Conversely, if the in-vehicle local time is detected to be less than the protocol request time, it proves that the time between the device sending the request to the OCSP server and the in-vehicle local time is too long, and the OCSP Stapling information may be invalid. Therefore, the authentication of the protocol request time fails.

[0064] In this embodiment, access verification of the device certificate includes certificate validity verification, certificate signature verification, and certificate status verification. Specifically, certificate validity verification is set to verify whether the device certificate is within its validity period. Certificate signature verification is set to verify whether the device certificate is a digital certificate for the device. Certificate status verification is set to verify whether the device certificate has been revoked based on the OCSP protocol.

[0065] The above verification of device certificates is only a partial verification. In other embodiments, verification of device certificates may also include verifying whether the device certificate format is correct, whether the OCSP information format is correct, and whether it is legal.

[0066] Step 106: If the access verification result is successful, grant the device access rights to the vehicle.

[0067] In some embodiments, if any one or more of the verifications for certificate validity period verification, certificate signature verification, and certificate status verification are not satisfied, the device's access to the vehicle will not be granted.

[0068] The following are the specific steps for verifying certificate validity, certificate signature, and certificate status:

[0069] (1) The steps for verifying the certificate validity period include: obtaining the OCSP detection time, which is the time between the protocol application time and the certification verification time. Checking whether the OCSP detection time is within the validity period of the device certificate. If the OCSP detection time is within the validity period, the device certificate is deemed valid. If the OCSP detection time is outside the validity period, the device certificate is deemed invalid.

[0070] For example, the device certificate's validity period is from 00:00 on October 6, 2024 to 12:00 on October 7, 2024. If the protocol application time is 11:50 on October 7, 2024, the OCSP information is valid at this time, and the OCSP information also has a validity period. For example, if the validity period of the OCSP information is 12 hours, then the validity period of the OCSP information is from 11:50 on October 7, 2024 to 23:50 on October 7, 2024. However, since the device certificate becomes invalid after 12:00 on October 7, 2024, the authentication of the device certificate will fail. Therefore, after the check between the protocol application time and the authentication verification time passes, it is necessary to check whether the OCSP check time is within the validity period of the device certificate.

[0071] In this embodiment, to ensure that the OCSP information is valid when the device sends an authentication request to the vehicle, when the authentication verification time includes the vehicle's local time, it is also necessary to further check whether the vehicle's local time is within the validity period of the OCSP information. If the vehicle's local time is detected to be within the validity period of the OCSP information, the OCSP information is determined to be valid. Otherwise, the OCSP information is determined to be invalid.

[0072] (2) The certificate signature verification steps include: sending a challenge message to the device, the challenge message being set to request the device to prove ownership of the device certificate, and the challenge message including an authentication random number; receiving a signature response message from the device, the signature response message being calculated by the device using the device's private key on the authentication random number; verifying the signature response message based on the device's public key; and determining that the device certificate is the device's digital certificate if the verification of the signature response message passes.

[0073] In this embodiment, a Challenge-Response process is used to verify whether the device certificate is a digital certificate of the device. Specifically, the vehicle generates a 32-byte authentication random number and sends it to the device via a 31 service response. The device calculates the authentication random number based on its private key and generates a signed response message. The device sends the signed response message to the vehicle. The vehicle uses the device certificate to parse the device's public key, and then verifies the signed response message based on the device's public key. If the verification passes, the device certificate is determined to be a digital certificate of the device. If the verification fails, the device certificate is determined not to be a digital certificate of the device.

[0074] By using the Challenge-Response process and OCSP information to jointly verify whether the device certificate is a digital certificate for the device, we can avoid the permanent leakage of the device's identity information due to the leakage of the device's private key, which could lead to the failure to revoke the device certificate in a timely manner, or the leakage of vehicle data caused by third parties forging device certificates to access the vehicle.

[0075] (3) The certificate status verification steps include: receiving the parsing result of the OCSP response from the device. The OCSP response is information received by the device from the OCSP server after being signed, based on the OCSP protocol and the device certificate. The device is configured to parse the signed OCSP response to obtain the parsing result. If the parsing result indicates that the certificate is not revoked, the device certificate status is determined to be unrevoked. Conversely, if the parsing result indicates that the certificate is revoked, the device certificate status is determined to be revoked.

[0076] In this embodiment, if the OCSP response determines that the device certificate has been revoked, the certificate status verification is deemed unsatisfactory, and the device's access permissions are determined to be restricted from granting the device access to the vehicle.

[0077] In some embodiments, the OCSP information includes access level information, and based on the access level information, the content of the access permissions granted to the device for the vehicle is determined.

[0078] When device access to the vehicle is not granted, a detection failure message is generated. This message is sent to the device so it can determine the reason for the failure. In this embodiment, the 31 service (Routine Control) from the UDS diagnostic protocol is used for device authentication. Most vehicles currently support the 31 service, thus using it for authentication offers good compatibility.

[0079] Compared with related technologies, the embodiments of this application have at least the following advantages:

[0080] To prevent vehicle data leakage, device authentication is required when a device sends an authentication request to a vehicle. This is achieved using the Online Certificate Status Protocol (OCSP), where the time the device sends the request to the OCSP server or receives the response is used as the protocol request time. Since this request time is fixed and unaffected by vehicle network connectivity, device authentication can be performed regardless of whether the vehicle or both are offline. Access to the vehicle is granted only when the authentication verification time and protocol request time, as well as the device certificate access verification, both pass. This dual verification of the relevant timeframes and the device certificate during authentication further ensures vehicle data security and prevents aftermarket diagnostic issues arising from failed device authentication.

[0081] Please refer to Figure 2, which is a schematic flowchart of another device access verification method provided in an embodiment of this application. This embodiment is applied to a vehicle, and the specific process is shown in Figure 2, including the following steps:

[0082] Step 201: Receive the device's authentication request, which includes the protocol application time and the device's certificate.

[0083] Step 202: Obtain the authentication verification time when the device sends the authentication request. The authentication verification time includes the world standard time and the vehicle's local time.

[0084] In this embodiment, the authentication verification time is a time determined based on Coordinated Universal Time (UTC). Meanwhile, the in-vehicle local time is a time determined based on UTC and the vehicle's location. The method for obtaining the in-vehicle local time is the same as in step 102, and step 201 is the same as in step 101; to avoid repetition, it will not be described again here.

[0085] Step 203: Calculate the first difference between Coordinated Universal Time and the agreement request time, and calculate the second difference between the in-vehicle local time and the agreement request time.

[0086] Step 204: Check whether the first difference is within the preset time difference range.

[0087] The preset time difference range includes a first preset difference range and a second preset difference range. The specific requirements for setting the first and second preset difference ranges can be found in step 104. In this embodiment, it is detected whether the first difference is within the first preset difference range.

[0088] Step 205: When the first difference is detected to be outside the preset time difference range, detect whether the second difference is within the preset time difference range.

[0089] In this embodiment, when the first difference is detected to be outside the first preset difference range, the second difference is detected to be within the second preset difference range.

[0090] Step 206: When the second difference is detected to be within the preset time difference range, the device certificate is accessed and verified.

[0091] In this embodiment, when a second difference is detected within a second preset difference range, the device certificate is access verified.

[0092] In other embodiments, when the second difference is detected to be outside the range of the second preset difference, it may also be detected whether the in-vehicle local time is earlier than the protocol request time.

[0093] By detecting whether the vehicle's local time is earlier than the protocol request time, it can be determined whether there is a significant time regression. When the vehicle's local time is detected to be earlier than the protocol request time, a significant time regression is observed, and the vehicle's local time can no longer be used to detect the protocol request time. This is to avoid detection errors that could lead to persistent authentication failures for the device, preventing the device from accessing the vehicle. The specific detection process has been described in detail above and will not be repeated here.

[0094] Step 207: If the access verification result is successful, grant the device access rights to the vehicle.

[0095] The specific content of access verification for the device certificate is the same as that of access verification for the device certificate in step 106, and will not be repeated here.

[0096] When device access to the vehicle is not granted, a detection failure message is generated. This message is then sent to the device so it can determine the reason for the failure.

[0097] Compared with related technologies, the embodiments of this application have at least the following advantages:

[0098] When a device sends an authentication request to a vehicle, device authentication is required to prevent vehicle data leakage. On one hand, the time when the device sends the request to the OCSP server or receives the response from the OCSP server, based on the Online Certificate Status Protocol (OCSP), is used as the protocol request time. First, a first difference is checked to see if it falls within a first preset difference range, then a second difference is checked to see if it falls within a second preset difference range. This joint detection of the first and second differences improves the accuracy of device authentication. On the other hand, it can also detect whether the protocol request time is earlier than the vehicle's local time. Based on the detection results, it can be determined whether the protocol request time meets the authentication requirements and whether the vehicle's local time has significantly declined. When the vehicle's local time has significantly declined, the detection between the vehicle's local time and the protocol request time is skipped, thus avoiding authentication failures due to incorrect vehicle local time, which would affect the device's access to the vehicle. Furthermore, using the time when the device sends the request to the OCSP server or receives the response from the OCSP server as the protocol request time solves the problem that the vehicle must be connected to the internet for relevant time checks to be performed on the device's authentication. On the other hand, by double-checking the relevant time and device certificate in the device identity authentication process, the security of vehicle data is further guaranteed.

[0099] Please refer to Figure 3, which is an interactive schematic diagram of a vehicle authenticating its identity with a device according to an embodiment of this application.

[0100] Step S11: When the device detects that it does not have a local device certificate, it sends a certificate request to the certificate server.

[0101] In some embodiments, before sending an authentication request to the vehicle, the device checks if a usable digital certificate exists locally. If no usable digital certificate is detected, the device generates a public and private key pair, uploads the public key and certificate request information to a certificate server to request the certificate server to issue a digital certificate. Specifically, the device requests a Certificate Authority (CA) to issue a digital certificate.

[0102] Step S12: The certificate server sends the device certificate to the device.

[0103] In this embodiment, based on the public key and certificate application information, the CA sends the digital certificate to the device. After receiving the digital certificate sent by the CA, the device uses the digital certificate as its device certificate.

[0104] Step S13: The device sends an authentication request to the vehicle, wherein the authentication request includes the protocol application time and the device's device certificate.

[0105] After a device obtains a digital certificate from a Certificate Authority (CA), and when the device needs to access the vehicle, it sends a request to the CA's OCSP server based on the Online Certificate Status Protocol (OCSP) to obtain an OCSP response for the digital certificate. The OCSP server then sends an OCSP response (which includes OCSP Stapling information, also known as OCSP binding information) to the device. The OCSP Stapling query inquires about the status of the digital certificate. OCSP is an online query protocol used to verify the legitimacy of certificates. The OCSP response contains certificate status information, such as whether it has been revoked or is valid, thus verifying the certificate's validity.

[0106] In this embodiment, the protocol request time is the time when the device sends a request to the OCSP server or the time when the device receives a response from the OCSP server, based on the OCSP protocol.

[0107] Step S14: The authentication verification time when the vehicle acquisition device sends an authentication request. The authentication verification time is a time determined based on Coordinated Universal Time.

[0108] In one embodiment, the authentication verification time includes Coordinated Universal Time (UTC) or in-vehicle local time. UTC is also known as Coordinated Universal Time or Coordinated International Time. The authentication verification time includes the in-vehicle local time. The in-vehicle local time is determined based on UTC and the vehicle's location. In this embodiment, the in-vehicle local time is maintained by a crystal oscillator within the vehicle. The crystal oscillator primarily uses a high-precision oscillation frequency to localize the vehicle's calculated time.

[0109] In another embodiment, the authentication verification time includes Coordinated Universal Time (UTC) and the vehicle's local time.

[0110] It should be noted that the method for obtaining Coordinated Universal Time and / or in-vehicle local time can be found in step 102, and will not be described here.

[0111] Step S15: Calculate the time difference between the vehicle's authentication verification time and the protocol application time.

[0112] In some embodiments, when the authentication verification time includes Coordinated Universal Time (UTC) or in-vehicle local time, the time difference between UTC and the protocol application time is calculated, and this time difference is used as the first difference. Alternatively, the time difference between in-vehicle local time and the protocol application time is calculated, and this time difference is used as the second difference.

[0113] In another embodiment, when the authentication verification time includes both Coordinated Universal Time (UTC) and in-vehicle local time, a first difference between UTC and the protocol request time and a second difference between in-vehicle local time and the protocol request time are calculated.

[0114] Step S16: If the detected time difference is within the preset time difference range, perform access verification on the device certificate.

[0115] The preset time difference range includes a first preset difference range and a second preset difference range. The specific ranges of the first and second preset difference ranges can be found in the relevant content of step 104.

[0116] In one embodiment, when the authentication verification time includes Coordinated Universal Time (UTC) or the vehicle's local time, a first difference is detected to be within a first preset difference range. If the first difference is detected to be within the first preset difference range, access verification of the device certificate is performed. Alternatively, a second difference is detected to be within a second preset difference range. If the second difference is detected to be within the second preset difference range, access verification of the device certificate is performed.

[0117] In another embodiment, when the authentication verification time includes both Coordinated Universal Time (UTC) and the vehicle's local time, a first difference is detected as being within a first preset difference range, and a second difference is detected as being within a second preset difference range. If the first difference is detected as being within the first preset difference range and the second difference is detected as being within the second preset difference range, access verification of the device certificate is performed.

[0118] The specific steps for access verification of the device certificate can be found in steps 105 and 106. To avoid repetition, they will not be repeated here.

[0119] Step S17: Determine the device's access permissions to the vehicle based on the access verification result.

[0120] If the device certificate access verification is successful, the vehicle will grant the device access permission. Otherwise, access will be denied to prevent vehicle data leakage in case of unauthorized access.

[0121] Compared with related technologies, the embodiments of this application have at least the following advantages:

[0122] When a device sends an authentication request to a vehicle, device authentication is required to prevent vehicle data leakage. This is achieved by using the Online Certificate Status Protocol (OCSP), where the time the device sends the request to the OCSP server or receives the response is used as the protocol request time. This request time is then compared with Coordinated Universal Time (UTC) or the vehicle's local time, thus resolving the issue of requiring a vehicle internet connection for time-related checks during device authentication. Once both the authentication verification time and the protocol request time, as well as the device certificate access verification, pass, access to the vehicle is granted. This dual verification of relevant times and the device certificate during authentication further ensures vehicle data security.

[0123] Please refer to Figure 4, which is another interactive schematic diagram of a vehicle authenticating its identity with a device according to an embodiment of this application.

[0124] Step S21: When the device detects that it does not have a local device certificate, it sends a certificate request to the certificate server.

[0125] Step S22: The certificate server sends the device certificate to the device.

[0126] Step S23: The device sends an authentication request to the vehicle, wherein the authentication request includes the protocol application time and the device's device certificate.

[0127] The specific content of steps S21 to S23 is the same as that of steps S11 to S13, and will not be repeated here to avoid repetition.

[0128] Step S24: The vehicle obtains the authentication verification time, which includes the world standard time and the vehicle's local time.

[0129] In this embodiment, the in-vehicle local time is determined based on Coordinated Universal Time (UTC) and the vehicle's location. The method for obtaining the in-vehicle local time can be found in step 102.

[0130] Step S25: The vehicle calculates the first difference between the Coordinated Universal Time (UTC) and the protocol request time, and calculates the second difference between the vehicle's local time and the protocol request time.

[0131] Step S26: Check whether the first difference in vehicle detection is within the preset time difference range.

[0132] The preset time difference range includes a first preset difference range and a second preset difference range. The specific requirements for setting the first and second preset difference ranges can be found in step 104. In this embodiment, it is detected whether the first difference is within the first preset difference range.

[0133] Step S27: When the vehicle detects that the first difference is not within the preset time difference range, it detects whether the second difference is within the preset time difference range.

[0134] In this embodiment, when the first difference is detected to be outside the first preset difference range, the second difference is detected to be within the second preset difference range.

[0135] Step S28: When the vehicle detects that the second difference is within the preset time difference range, it performs access verification of the device certificate.

[0136] In this embodiment, when a second difference is detected within a second preset difference range, the device certificate is access verified.

[0137] In other embodiments, when the second difference is detected to be outside the range of the second preset difference, it may also be detected whether the in-vehicle local time is earlier than the protocol request time.

[0138] For details of this step, please refer to step 206. To avoid repetition, it will not be repeated here.

[0139] Step S29: Determine the device's access permissions to the vehicle based on the access verification results.

[0140] If the device certificate access verification is successful, the vehicle will grant the device access permission. Otherwise, access will be denied to prevent vehicle data leakage in case of unauthorized access.

[0141] Compared with related technologies, the embodiments of this application have at least the following advantages:

[0142] When a device sends an authentication request to a vehicle, device authentication is required to prevent vehicle data leakage. Firstly, based on the Online Certificate Status Protocol (OCSP), the time when the device sends the request to the OCSP server or receives the response from the OCSP server is used as the protocol request time. The system checks whether the protocol request time is earlier than the vehicle's local time to determine if the request time meets authentication requirements and whether the vehicle's local time has significantly declined. If the vehicle's local time has significantly declined, the check between the vehicle's local time and the protocol request time is skipped, thus preventing authentication failures due to incorrect vehicle local time and ensuring device access to the vehicle. Secondly, using the time when the device sends the request to the OCSP server or receives the response from the OCSP server as the protocol request time solves the problem that the vehicle must be connected to the internet for time-related checks in device authentication. Thirdly, by double-checking the relevant times in device authentication and the device certificate, the security of vehicle data is further guaranteed.

[0143] Please refer to Figure 5. In one embodiment of this application, a vehicle is also provided. The vehicle includes a receiving module, an acquisition module, a calculation module, a detection module, a verification module, and an access control module.

[0144] The receiving module is configured to receive authentication requests from devices. The authentication request includes the protocol request time and the device's certificate. The protocol request time is the time when the device sends the request to the Online Certificate Status Protocol (OCSP) server or the time when the device receives the OCSP server.

[0145] The acquisition module is set to acquire the authentication verification time when the device issues an authentication request. The authentication verification time is a time determined based on Coordinated Universal Time.

[0146] The calculation module is set to calculate the time difference between the authentication verification time and the protocol application time.

[0147] The detection module is set to detect whether the time difference is within a preset time difference range.

[0148] The verification module is configured to perform access verification on the device certificate if the detected time difference is within a preset time difference range.

[0149] The access control module is configured to grant the device access rights to the vehicle if the access verification result is successful.

[0150] Please refer to Figure 6, which is a schematic diagram of the hardware structure of the electronic device 1000 provided in this embodiment of the application. As shown in Figure 6, the electronic device 1000 may include a processor 1001 and a memory 1002. The memory 1002 is configured to store one or more computer programs 1003. The one or more computer programs 1003 are configured to be executed by the processor 1001. The one or more computer programs 1003 include instructions that can be used to implement the device access verification method described above in the electronic device 1000.

[0151] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 1000. In other embodiments, the electronic device 1000 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements.

[0152] Processor 1001 may include one or more processing units, such as application processors (APs), modems, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0153] The processor 1001 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 1001 is a cache memory. This memory can store instructions or data that the processor 1001 has just used or that are used repeatedly. If the processor 1001 needs to use the instruction or data again, it can retrieve it directly from this memory. This avoids repeated accesses, reduces the waiting time of the processor 1001, and thus improves the efficiency of the system.

[0154] In some embodiments, the processor 1001 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a SIM interface, and / or a USB interface, etc.

[0155] In some embodiments, the processor 1001 is also configured to execute acceleration schemes such as Single Instruction Multiple Data (SIMD) and Very Long Instruction Word (VLIW).

[0156] In some embodiments, memory 1002 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0157] This embodiment also provides a computer-readable storage medium storing computer instructions. When the instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the device access verification method in the above embodiment.

[0158] In this embodiment, the electronic device and storage medium are used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0159] In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

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

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

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

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

[0164] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the scope of protection of this application.

Claims

1. A device access authentication method, applied to a vehicle, the method comprising: The device receives an authentication request, which includes a protocol request time and the device certificate. The protocol request time is the time when the device sends the request to the Online Certificate Status Protocol (OCSP) server or the time when the device receives the response from the OCSP server. The authentication verification time when the device sends the authentication request is obtained, and the authentication verification time is a time determined based on Coordinated Universal Time. Calculate the time difference between the authentication verification time and the protocol application time; Detect whether the time difference is within a preset time difference range; If the time difference is detected to be within the preset time difference range, the device certificate is access verified. If the access verification result is successful, the device is granted access to the vehicle.

2. The device access verification method according to claim 1, wherein, The authentication verification time includes Coordinated Universal Time (UTC); calculating the time difference between the authentication verification time and the protocol application time includes: Calculate the first difference between the Coordinated Universal Time (UTC) and the protocol request time; The step of detecting whether the time difference is within a preset time difference range includes: Detect whether the first difference is within the preset time difference range; If the time difference is detected to be within the preset time difference range, the access verification of the device certificate includes: If the first difference is detected to be within the preset time difference range, the device certificate is access verified.

3. The device access verification method according to claim 1, wherein, The authentication verification time includes the in-vehicle local time, which is a time determined based on the Coordinated Universal Time (UTC) and the vehicle's location. The calculation of the time difference between the authentication verification time and the protocol application time includes: Calculate the second difference between the in-vehicle local time and the protocol request time; The step of detecting whether the time difference is within a preset time difference range includes: Detect whether the second difference is within the preset time difference range; If the time difference is detected to be within the preset time difference range, the access verification of the device certificate includes: If the second difference is detected to be within the preset time difference range, the device certificate is access verified.

4. The device access verification method according to claim 3, wherein, After detecting whether the second difference is within the preset time difference range, the method further includes: If the second difference is detected to be outside the preset time difference range, detect whether the in-vehicle local time is earlier than the protocol application time; If the in-vehicle local time is detected to be earlier than the protocol application time, the device certificate is accessed and verified.

5. The device access verification method according to claim 1, wherein, The authentication verification time includes Coordinated Universal Time (UTC) and the vehicle's local time, which is determined based on the UTC and the vehicle's location. The time difference includes a first difference and a second difference. Calculating the time difference between the authentication verification time and the protocol application time includes: Calculate the first difference between the Coordinated Universal Time (UTC) and the protocol request time, and calculate the second difference between the in-vehicle local time and the protocol request time; The step of detecting whether the time difference is within a preset time difference range includes: Detect whether the first difference is within the preset time difference range; If the first difference is detected to be outside the preset time difference range, then the second difference is detected to be within the preset time difference range. If the time difference is detected to be within the preset time difference range, the access verification of the device certificate includes: If the second difference is detected to be within the preset time difference range, the device certificate is access verified.

6. The device access verification method according to claim 5, wherein, The step of verifying the device certificate if the time difference is detected to be within the preset time difference range further includes: If the second difference is detected to be outside the preset time difference range, it is detected whether the in-vehicle local time is earlier than the protocol application time. If the in-vehicle local time is detected to be earlier than the protocol application time, the device certificate is accessed and verified.

7. The device access verification method according to any one of claims 1 to 6, wherein, The application request includes status information requesting the device certificate.

8. The device access verification method according to any one of claims 1 to 7, wherein, The access verification of the device certificate includes: Obtain the OCSP detection time and the validity period of the device certificate, wherein the OCSP detection time is the time between the protocol application time and the certification verification time during which the detection is successful; Check whether the OCSP testing time is within the certificate validity period; If the OCSP detection time is detected within the certificate validity period, the device certificate is determined to be valid. If the OCSP detection time is detected to be outside the certificate validity period, the device certificate is determined to be invalid.

9. The device access verification method according to any one of claims 1 to 7, wherein, The access verification of the device certificate includes: Send a challenge message to the device, the challenge message being configured to request the device to prove ownership of the device certificate, the challenge message including an authentication random number; Receive a signature response message from the device, wherein the signature response message is obtained by the device using the device's private key to calculate the authentication random number; The signed response message is verified based on the public key of the device; If the verification of the signed response message passes, the device certificate is determined to be the digital certificate of the device.

10. The device access verification method according to any one of claims 1 to 7, wherein, The access verification of the device certificate includes: The device receives the parsing result of the OCSP response from the device, wherein the OCSP response is information received by the device based on the OCSP protocol and the device certificate after being signed by the OCSP server, and the device is configured to parse the signed OCSP response to obtain the parsing result; If the parsing result is "not revoked", the status of the device certificate is determined to be "not revoked".

11. A vehicle, wherein, The vehicles include: The receiving module is configured to receive authentication requests from devices. The authentication request includes a protocol application time and the device certificate of the device. The protocol application time is the time when the device sends an application request to the Online Certificate Status Protocol (OCSP) server or the time when the device receives the OCSP server. The acquisition module is configured to acquire the authentication verification time when the device issues the authentication request, wherein the authentication verification time is a time determined based on Coordinated Universal Time. The calculation module is configured to calculate the time difference between the authentication verification time and the protocol application time; The detection module is configured to detect whether the time difference is within a preset time difference range; The verification module is configured to perform access verification on the device certificate if the time difference is detected to be within the preset time difference range. The access control module is configured to grant the device access rights to the vehicle if the access verification result is successful.

12. An electronic device, wherein, The electronic device includes a processor and a memory, the memory being configured to store instructions, and the processor being configured to invoke the instructions in the memory, causing the electronic device to execute the access verification method of the device according to any one of claims 1 to 10.

13. A computer storage medium, wherein, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform an access verification method for the device as claimed in any one of claims 1 to 10.

Images