Authentication methods, devices, vehicles and storage media

Abstract

This application provides an authentication method, device, vehicle, and storage medium. The method, applied in the field of intelligent connected vehicle technology, receives a signature description file issued by a cloud server. The signature description file includes multi-level certificate chain signature information, obtained by signing the global root certificate, regional certificates, and service certificates at each level. The signature description file is then verified using a pre-stored public key of the global root certificate. If the verification passes, a firmware upgrade package corresponding to the signature description file is downloaded from the cloud server to update the vehicle software. This method improves the security of firmware upgrade package applications by setting the global root certificate, regional certificates, and service certificates as a three-level chain verification signature.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and more specifically, to an authentication method, apparatus, vehicle, and storage medium in the field of intelligent connected vehicle technology. Background Technology

[0002] With the rapid development of intelligent connected vehicles, over-the-air (OTA) technology has become a core means of functional iteration, vulnerability patching, and performance optimization throughout the entire vehicle lifecycle. At the same time, major economies worldwide are imposing increasingly stringent compliance requirements on intelligent connected vehicles, demanding that vehicle software upgrade packages be strictly limited to specific geographical or legal jurisdictions, prohibiting cross-regional deployment and installation.

[0003] However, current mainstream automotive OTA systems generally lack effective regional binding and access control mechanisms at the firmware level. The cloud typically uses a single global root certificate system to sign firmware upgrade packages for all regions, resulting in the indistinguishability of the digital signature of the same upgrade package across different regions. This allows some individuals to carry out illegal cross-region flashing activities such as forcibly flashing firmware from country A to vehicles from country B.

[0004] Therefore, current vehicle software upgrade technology cannot completely prevent the cross-regional deployment and installation of vehicle software upgrade packages, resulting in the inability of current vehicle software upgrade technology to meet the relevant compliance requirements of intelligent connected vehicles. Summary of the Invention

[0005] This application provides an authentication method, device, vehicle, and storage medium. This method can solve the technical problem that current vehicle software upgrade technologies cannot completely prevent the cross-regional deployment and installation of vehicle software upgrade packages, thus failing to meet the relevant compliance requirements of intelligent connected vehicles.

[0006] Firstly, an authentication method is provided, which includes: Receive a signature description file issued by a cloud server, wherein the signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate and service certificate level by level; The signature description file is verified through a multi-level chain based on the pre-stored global root certificate public key. If the verification is successful, the firmware upgrade package corresponding to the signature description file is downloaded from the cloud server to update the vehicle software according to the firmware upgrade package.

[0007] The beneficial effects of the technical solution described in the first aspect above include at least the following: By adopting an architecture of hierarchical signing using a global root certificate, regional certificates, and service certificates, the signature information of the firmware upgrade package is expanded into a three-level chain structure. In this case, the vehicle can use its locally pre-stored global root certificate public key to perform multi-level chain verification of the signature description file. If any level of signature fails verification, the entire trust chain is considered broken, and its reliability cannot be guaranteed. Furthermore, since firmware upgrade packages from different regions are signed by different regional certificates, the certificate chain structure in their signature description files does not match the certificate system trusted by the vehicle's pre-stored root certificate public key. Multi-level chain verification will inevitably fail due to the failure of the regional certificate verification step. This prevents the vehicle from obtaining the firmware upgrade package across regions before it downloads it from another region. Compared to the existing single global root certificate signing scheme (i.e., firmware upgrade packages from all regions are signed by the same global root certificate public key), this approach offers significant advantages. A single root certificate verification cannot verify whether the vehicle has downloaded software from a different region. However, the multi-level certificate chain verification method described above can circumvent this situation. At the same time, on this basis, regional control capabilities are pushed down to the signature verification level. The vehicle only needs to use the locally pre-stored global root certificate public key to complete the corresponding chain verification, without the need for multiple real-time certificate status interactions with the cloud. This ensures that even when the vehicle is offline, it can accurately identify and reject signature description files from other regions. This makes regional isolation capabilities independent of network connection status, avoids the risks caused by multiple information interactions between the vehicle and the cloud, and avoids the possibility of forcibly refreshing the vehicle software across regions through technical means during multiple interactions. This prohibits the cross-regional deployment and installation of vehicle software upgrade packages, ensuring that the current vehicle software upgrade technology can meet the relevant compliance requirements of intelligent connected vehicles.

[0008] Among some possible implementations, the above authentication methods include: The multi-level certificate chain signature information includes root certificate signature, zone-level signature, service-level signature, global root certificate, zone certificate, and service certificate; The root certificate signature is obtained by signing the hash value and corresponding regional attributes of the regional certificate using the global root certificate. The region-level signature is obtained by signing the hash value of the service certificate and the corresponding region code using the region-level certificate. The service-level signature is obtained by signing the digest information and the region code of the corresponding firmware upgrade package using the service certificate.

[0009] By employing the technical solutions described above in the possible implementation methods, a chain-like multi-level certificate signing process is achieved by signing the regional certificate with the global root certificate, signing the service certificate with the regional certificate, and signing the corresponding summary information of the firmware upgrade package with the service certificate. This improves the credibility of the signed information. At the same time, by relying on the regional certificate contained in the signing result, the three-level chain-like signature verification is limited to the relevant regional content, thus avoiding the situation where the vehicle downloads the firmware upgrade package across regions.

[0010] Among some possible implementations, the above authentication methods include: Based on the pre-stored global root certificate public key, determine whether the root certificate signature in the multi-level certificate chain signature information is valid, so as to confirm whether the regional certificate was issued by the global root certificate. If the root certificate signature is valid, then based on the verified regional certificate public key, determine whether the regional signature in the multi-level certificate chain signature information is valid, so as to confirm whether the service certificate is issued by the regional certificate. If the regional signature verification is valid, then the validity of the regional certificate and the service certificate is determined. Obtain real-time information about the vehicle's current location and compare the area code with the real-time information. If the comparison results are consistent, the verification is successful.

[0011] Through the technical solutions in the above possible implementation methods, when the vehicle receives the signature description file sent from the cloud, it can perform multi-level verification according to the reverse chain of the multi-level certificate chain signature information generation process, thereby ensuring the reliability of the signature information. At the same time, the verification process only requires the vehicle to call the pre-stored global root certificate public key to complete the verification process of the entire multi-level certificate chain signature, avoiding the risks caused by multiple information exchanges between the vehicle and the cloud.

[0012] Among some possible implementations, the above authentication methods include: Calculate the summary information of the downloaded firmware upgrade package; Based on the verified public key of the service certificate in the signature description file, determine whether the digest information matches the corresponding service-level signature, and verify the service-level signature based on the verified public key of the region certificate in the signature description file; If both verifications pass, then install the firmware upgrade package.

[0013] Through the technical solutions described above in the possible implementation methods, after the firmware upgrade package is downloaded, it is also necessary to check the firmware upgrade package to avoid any interference or tampering during transmission, thus ensuring the reliability of the firmware upgrade package downloaded to the vehicle and improving the security of the firmware upgrade package downloaded to the vehicle.

[0014] Among some possible implementations, the above authentication methods include: The global root certificate public key is pre-installed in the trusted execution environment or security chip on the vehicle. The public key is read from the trusted execution environment or security chip through a preset public key infrastructure interface to ensure the physical security and tamper-proof nature of the trust anchor.

[0015] By employing the technical solutions described above in the possible implementation methods, the global root certificate public key is embedded in the vehicle's secure chip or trusted execution environment, thus avoiding the need for the vehicle to obtain the public key from the cloud and improving the security of public key usage.

[0016] Among some possible implementations, the above authentication methods include: The signature description file also includes description information corresponding to the multi-level certificate chain signature information, as well as a preset data checksum; The checksum of the description information and the signature data is calculated and compared with the data checksum to perform multi-level chain verification on the signature description file after confirming that the signature description file has not been tampered with during transmission.

[0017] Through the technical solutions in the above possible implementation methods, before verifying the multi-level certificate chain signature information in the signature description file, the signature description file can be simply verified by the description information in the signature description file and the preset data checksum, thereby ensuring the reliability of the signature description file and avoiding the wasted effort of subsequent chain multi-level verification.

[0018] Among some possible implementations, the above authentication methods include: If the regional certificate is replaced, the new generation of regional certificate is issued by the previous generation regional certificate, and the trust chain is verified by tracing back to the global root certificate level by level to ensure the seamless rotation of the regional certificate.

[0019] Through the technical solutions in the above possible implementation methods, when a regional certificate is iteratively replaced, the new generation regional certificate can be directly signed and authenticated using the old previous generation regional certificate. This allows the new regional certificate to be incorporated into the multi-level certificate chain signature information without changing other certificates and signature information in its chain structure, thus improving the efficiency of regional certificate replacement.

[0020] Secondly, an authentication device is provided, the device comprising: The receiving module is used to receive a signature description file sent by the cloud server. The signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate and service certificate level by level. The verification module is used to perform multi-level chain verification on the signature description file based on the pre-stored global root certificate public key; The update module is used to download the firmware upgrade package corresponding to the signature description file from the cloud server if the verification is successful, so as to update the vehicle software according to the firmware upgrade package.

[0021] Thirdly, a vehicle is provided, including a memory for storing executable program code; and a processor for calling and running the executable program code from the memory, causing the vehicle to perform the methods described in the first aspect or any possible implementation thereof.

[0022] Fourthly, a computer program product is provided, comprising: computer program code, which, when run on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof.

[0023] Fifthly, a computer-readable storage medium is provided that stores computer program code, which, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible implementation thereof. Attached Figure Description

[0024] Figure 1 An exemplary system architecture diagram of an authentication method provided in this application embodiment; Figure 2 A flowchart illustrating an authentication method provided in an embodiment of this application; Figure 3 A flowchart illustrating an authentication method provided in an embodiment of this application; Figure 4 A flowchart illustrating an authentication method provided in an embodiment of this application; Figure 5 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0025] To make the features and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. Furthermore, in the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments of this application, "multiple" refers to two or more.

[0027] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0028] With the rapid development of intelligent connected vehicles, OTA (Over-The-Air) technology has become a core means of functional iteration, vulnerability repair, and performance optimization throughout the entire vehicle lifecycle. Modern vehicles typically contain dozens or even hundreds of electronic control units, covering multiple functional domains such as powertrain, autonomous driving, infotainment, and body control. OTA technology allows for remote patching of security vulnerabilities, optimization of the driving experience, and addition of new features, significantly reducing recall costs for automakers and time costs for users. However, major economies worldwide are increasingly stringent in their compliance requirements for intelligent connected vehicles, requiring that vehicle software upgrade packages be strictly limited to specific geographical or legal jurisdictions, prohibiting cross-regional deployment and installation.

[0029] However, current mainstream automotive OTA systems generally lack effective region binding and access control mechanisms at the firmware level. The cloud typically uses a single global root certificate system to sign firmware upgrade packages for all regions; that is, the global root certificate private key uniformly signs all upgrade packages, resulting in the indistinguishability of the digital signature of the same upgrade package across different regions. This architecture has a fundamental flaw: because all upgrade packages share the same trust anchor, once an attacker obtains any legitimate upgrade package (e.g., through network packet capture or extraction from a scrapped vehicle), they can repackage it and disguise it as a legitimate upgrade package from another region, tricking the vehicle into installation. In practical applications, there have been cases of Chinese firmware being forcibly flashed onto European vehicles, a serious violation of data sovereignty principles and product compliance requirements.

[0030] In existing technologies, some solutions attempt to filter at the software level by embedding region code fields in the upgrade package or using region whitelists. However, these measures are implemented at the application layer and are easily bypassed. Attackers can bypass software-level region restrictions by modifying upgrade package metadata, tampering with region identifiers, or performing replay attacks. More importantly, existing systems lack identity-based region access control mechanisms, making it impossible to trace the true source and issuing region of the upgrade package. When cross-regional unauthorized flashing occurs, automakers find it difficult to pinpoint the root cause of the problem through audit logs, failing to meet mandatory audit requirements related to privacy.

[0031] Furthermore, the current certificate management mechanism also faces the challenge of dynamic rotation of regional certificates. Regional certificates usually have validity periods (such as 3-5 years). When a certificate needs to be renewed, the existing solutions often require the vehicle to be returned to the factory for processing or rely on complex online certificate status query protocols. In scenarios where vehicles may be offline for a long time (such as parked in an underground garage), it is difficult to achieve seamless rotation. Once a regional certificate expires and the vehicle is not updated in time, all vehicles in that region will be unable to receive legitimate OTA upgrades, resulting in a large-scale recall risk.

[0032] In summary, existing vehicle software upgrade technologies cannot completely prevent the cross-regional deployment and installation of vehicle software upgrade packages, and cannot meet the mandatory compliance requirements of intelligent connected vehicles in areas such as regional software management, data sovereignty compliance, auditability, and dynamic certificate management. Therefore, there is an urgent need for an authentication method that can achieve regional binding at the cryptographic level, support multi-level certificate chain verification, and possess traceability and seamless certificate rotation capabilities. This would fundamentally solve the problem of unauthorized cross-regional software updates, ensure the compliance of vehicle software upgrades throughout their entire lifecycle, prevent the cross-regional deployment and installation of vehicle software upgrade packages, and enable vehicles to meet the relevant compliance requirements for intelligent connected vehicles.

[0033] Therefore, this application provides an authentication method to solve the above-mentioned technical problems.

[0034] Please see Figure 1 , Figure 1 An exemplary system architecture diagram of an authentication method provided in this application embodiment.

[0035] like Figure 1 As shown, the system architecture may include vehicle 101, network 102, and server 103. Network 102 serves as the medium for providing a communication link between vehicle 101 and server 103. Network 102 may include various types of wireless communication links, such as Near Field Communication (NFC), Ultra Wideband (UWB), Bluetooth, Wireless-Fidelity (Wi-Fi), or microwave communication links.

[0036] Vehicle 101 can interact with server 103 via network 102 to receive or send messages to server 103. Alternatively, vehicle 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Server 103 can be a business server providing various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0037] In this embodiment, vehicle 101 first receives a signature description file sent by a cloud server. The signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate, and service certificate at each level. Then, vehicle 101 performs multi-level chain verification on the signature description file based on the pre-stored global root certificate public key. Subsequently, if vehicle 101 determines that the verification is successful, it downloads the firmware upgrade package corresponding to the signature description file from the cloud server to update the vehicle software according to the firmware upgrade package.

[0038] The system architecture may or may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification, that is, the method provided in the embodiments of this application can be applied to a system structure that only includes vehicle 101, and the embodiments of this application do not limit this.

[0039] It should be understood that Figure 1The number of vehicles, networks, and servers shown is only illustrative; the number can be any number depending on the implementation requirements.

[0040] Please see Figure 2 , Figure 2 This is a flowchart illustrating an authentication method provided in an embodiment of this application. The executing entity in this embodiment can be a vehicle executing the authentication method, a processor within the vehicle executing the authentication method, or an authentication service within the vehicle executing the authentication method. For ease of description, the following example uses a processor within a vehicle as the executing entity to illustrate the specific execution process of the authentication method.

[0041] like Figure 2 As shown, authentication methods may include at least: S10. Receive a signature description file issued by the cloud server. The signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate and service certificate level by level. It should be noted that when the cloud server (hereinafter referred to as the cloud) releases the corresponding firmware upgrade package for vehicle software upgrade, the cloud platform only sends the information that the current vehicle has a usable firmware upgrade package to the corresponding vehicle terminal by broadcasting or pushing. The vehicle terminal then determines whether it needs to download the corresponding firmware upgrade package from the cloud. If a download is required, the vehicle terminal initiates the corresponding download request, and the cloud provides a signature description file for verification. Only after the verification is successful will the vehicle terminal be allowed to download the corresponding firmware upgrade package from the cloud.

[0042] First, the vehicle establishes a secure connection with the cloud through the vehicle communication module and receives the signature description file pushed by the cloud. This signature description file is a structured data block, which is usually encoded in JSON format. Its core content corresponds to multi-level certificate chain signature information and corresponding description information.

[0043] This application does not limit the number of levels of multi-level certificates. For example, it can be a three-level certificate consisting of a global root certificate, a regional certificate, and a service certificate, or a four-level certificate consisting of a global root certificate, a regional certificate, a national certificate, and a service certificate.

[0044] Specifically, as a preferred embodiment, the multi-level certificate chain signature information refers to linking multiple levels such as global root certificates, regional certificates, and service certificates through a step-by-step signing method to construct a fixed hierarchical chain information structure, forming a trusted chain from the highest trust anchor point to the underlying entity certificate.

[0045] Specifically, the global root certificate (held by the root certificate authority of the automotive group or industry alliance) signs the regional certificate to prove that the regional certificate was legally issued. Then, the service certificate is signed by the regional certificate (for example, held by the sub-certificate authority responsible for the Asia-Pacific region) to prove that the service certificate belongs to a specific service (such as OTA upgrade service). Finally, the service certificate signs the digest information of the firmware upgrade package to ensure the integrity and authenticity of the upgrade package.

[0046] In this embodiment, the multi-level certificate chain signature information includes at least the root certificate signature, the region-level signature, the service-level signature, the global root certificate, the region-level certificate, and the service certificate. Root certificate signing is obtained by signing the hash value and corresponding zone attributes of the zone certificate using the global root certificate. A region-level signature is obtained by signing the hash value of the service certificate and the corresponding region code using a region-level certificate. Service-level signatures are obtained by signing the digest information and region code of the corresponding firmware upgrade package using a service certificate.

[0047] Understandably, a multi-level certificate chain signature is a composite data structure containing six core elements, including the root certificate signature, zone signature, service signature, global root certificate, zone certificate, and service certificate.

[0048] Among them, the global root certificate is the highest-level certificate in the entire trust system. It is held by the root certificate authority of the car manufacturer group or industry alliance. This certificate is usually self-signed, and its public key is pre-configured in the local chip of each vehicle. The validity period of the root certificate is usually very long, such as 20 or 30 years. The root certificate contains the issuer information, validity period, subject public key information, and extended fields, in which the type and purpose of the root certificate can be defined.

[0049] Regional certificates are secondary certificates issued by the global root certificate and are used to manage certificate issuance services for specific geographic regions. For example, the global root certificate can sign different regional certificates for specific regions, such as the Asia-Pacific region, the European region, and the North American region. The validity period of a regional certificate is usually 3 to 5 years, and its extended fields contain specific regional attributes, such as the region code, region name, and jurisdiction description.

[0050] Among them, the service certificate is a multi-level certificate issued by the regional certificate, which is used to represent a specific online service. In the OTA upgrade scenario, the service certificate corresponds to the firmware upgrade service. The validity period of the service certificate is usually 1 to 2 years. Its extended fields include the regional code (which is the same as or a subset of the regional code of the superior regional certificate) and the service type identifier.

[0051] The root certificate signature is obtained by digitally signing the hash value and corresponding regional attributes of the regional certificate using the global root certificate. The specific calculation process is as follows: first, calculate the hash value of the complete DER (Distinguished Encoding Rules) encoding of the regional certificate; then, concatenate the hash value with the regional attributes in the extended field of the regional certificate; and finally, sign the concatenation result using the private key of the global root certificate, thereby ensuring the non-repudiation of the regional certificate and its regional attributes.

[0052] The region-level signature is obtained by signing the hash value of the service certificate and the corresponding region code using the region-level certificate. The calculation process is similar to that of the root certificate signature: first, the hash value of the service certificate is calculated, then concatenated with the region code, and finally signed with the private key of the region-level certificate. This ensures the binding of the service certificate to a specific region and prevents the service certificate from being abused across regions.

[0053] The service-level signature is obtained by signing the digest information and region code of the corresponding firmware upgrade package using a service certificate. The digest information refers to the hash value of the firmware upgrade package, and the region code is used to further determine that the upgrade package is only applicable to vehicles in a specific region. This signature ensures the integrity of the final firmware upgrade package.

[0054] In summary, through this chain structure of multi-level certificate signing, the leakage of any level of certificate will not cause security problems for the entire system. For example, if the private key of a certain regional certificate is leaked, the attacker can only forge service certificates in that region and cannot affect other regions. At the same time, the global root certificate can revoke the regional certificate and issue a new regional certificate to replace it. In addition, relying on the content of the regional code in the multi-level certificate signing information, the specific regional location to which the vehicle belongs during verification is directly limited, avoiding the situation of randomly flashing vehicle software across regions.

[0055] S20. Perform multi-level chain verification on the signature description file based on the pre-stored global root certificate public key; In this embodiment, after receiving the signature description file, the vehicle needs to verify the trustworthiness of the three-level chain. First, the vehicle has a pre-stored global root certificate public key at the factory. This public key is the anchor of the entire trust system and can be stored in a corresponding security chip to ensure its security and reliability and prevent tampering. At this time, the vehicle can use the public key to perform multi-level chain verification of the signature description file, which specifically includes the following steps: The first step is to use the global root certificate public key to verify the root certificate signature and confirm whether the regional certificate was indeed issued by the global root certificate. The second step is to use the verified regional certificate public key to verify the regional signature and confirm whether the service certificate was signed by the regional certificate. The third step is to check whether the regional attribute in the certificate matches the current region of the vehicle. Only if all verification steps pass and are performed in this chain of verification order can the signature description file be considered trustworthy.

[0056] In this embodiment, before the step of performing multi-level chain verification of the signature description file based on the pre-stored global root certificate public key, the method further includes: The signature description file also includes descriptions of the multi-level certificate chain signature information, as well as pre-set data checksums; The checksum of the description information and the signature data is calculated and compared with the data checksum. After confirming that the signature description file has not been tampered with during transmission, a multi-level chain verification is performed on the signature description file.

[0057] In this embodiment, before verifying the multi-level certificate chain signature information, an additional layer of integrity verification is added to the signature description file itself. The signature description file also includes the corresponding description information of the multi-level certificate chain signature information, as well as a preset data checksum. The description information includes at least the checksum field in the signature description file, as well as the relevant metadata of the multi-level certificates, each level of signature, and firmware upgrade package (such as version number, file size, and timeliness information). The preset data checksum is a hash value or check value calculated by the cloud server on the entire file content when generating the signature description file, and is appended to the end of the file.

[0058] Specifically, after receiving the signature description file, the vehicle first calculates the checksum between the description information and the signature data. The vehicle extracts all data from the signature description file except for the checksum field, calculates the checksum using the same algorithm as the cloud server, reads the preset data checksum from the signature description file, and compares the two to determine whether they are consistent.

[0059] If the two match, it means that the signature description file has not been tampered with during the transmission from the cloud server to the vehicle, i.e., no bit flipping, data truncation, man-in-the-middle injection, or other attacks have occurred. Only after confirming that the signature description file has not been tampered with during transmission will the vehicle continue to perform multi-level chain verification. In this way, by verifying the overall integrity first and then verifying the digital signature in a layered verification measurement, transmission errors can be detected in advance, avoiding the execution of costly asymmetric cryptographic operations on invalid data and improving verification efficiency.

[0060] At the same time, if the two are inconsistent, that is, the checksums do not match, the vehicle should discard the signature description file, request a retransmission from the cloud, and record the security event log.

[0061] S30. If the verification is successful, download the firmware upgrade package corresponding to the signature description file from the cloud server to update the vehicle software according to the firmware upgrade package.

[0062] In this embodiment, if the verification passes, the vehicle can initiate a download request to the cloud and download the firmware upgrade package corresponding to the signature description file. The download process can employ a segmented download and breakpoint resume mechanism, performing integrity verification on each segment. After downloading, the corresponding software is upgraded and updated according to the contents of the firmware upgrade package. Throughout this process, the vehicle does not need to rely on an external network for real-time certificate verification. Furthermore, because the trust chain is embedded in the signature description file, verification can be completed offline. This reduces the number of information interactions, avoids potential security risks during interactions, and is suitable for various network signal conditions, improving verification efficiency.

[0063] In this embodiment, after the step of downloading the firmware upgrade package corresponding to the signature description file from the cloud server if the verification passes, the method further includes: If a regional certificate is replaced, the previous generation of regional certificates will be used to issue the new generation of regional certificates. The trust chain will be verified by tracing back to the global root certificate level by level to ensure a seamless replacement of regional certificates.

[0064] In this embodiment, if a regional certificate needs to be replaced, the possible reasons include: the regional certificate is nearing its expiration date, the regional certificate's private key is suspected of being leaked, or the regional certificate needs to have new extended fields added (such as modifying the regional attribute).

[0065] At this point, a new generation of regional certificates can be issued using the previous generation regional certificate. The specific process is as follows: Assuming the vehicle currently holds a regional certificate of version v1, valid from January 1, 2024 to January 1, 2027, on July 1, 2026 (six months in advance), the cloud will begin preparing the new generation regional certificate v2. At this time, the cloud can use the private key of v1 to sign the certificate signing request for v2, generating a new regional certificate v2. In this new certificate, the issuer field points to v1, while the subject field contains the identity information of the new generation certificate. Simultaneously, the validity period of the new certificate is set to July 1, 2026 to July 1, 2029, with a six-month overlap with the old certificate to ensure a smooth transition.

[0066] Furthermore, when the OTA upgrade process is triggered again on the vehicle side, the signature description file issued by the cloud will contain both the old certificate and the new certificate, or the new certificate will be pushed to the vehicle side through a separate certificate update channel. After the vehicle side receives the new certificate, it needs to verify the new certificate by tracing back to the global root certificate level by level to perform a trust chain verification, that is, by verifying the certificates at each level in the above-mentioned multi-level certificate chain signature information.

[0067] Specifically, the vehicle verifies the new certificate step by step, starting with the new certificate. First, it verifies whether the signature of the new certificate was issued by the old certificate (i.e., verifying the signature of the new certificate using the public key of the old certificate). Then, it verifies whether the signature of the old certificate was issued by the global root certificate (i.e., verifying the signature of the old certificate using the public key of the root certificate). Since the old certificate has already been trusted by the vehicle through the previous verifications, and the global root certificate is the absolute trust anchor, this chain-like tracing can prove the legitimacy of the new certificate, thereby ensuring the seamless rotation of regional certificates.

[0068] Furthermore, after the vehicle completes the hierarchical chain verification of the new certificate, it stores the new certificate in its local secure storage area, replacing the old certificate. In the next multi-level chain verification of the signature description file, the vehicle will use the new certificate as the region-level certificate for verification. Meanwhile, throughout the entire process, the vehicle does not need to perform complex online certificate status queries with the cloud, nor does it need to download the complete certificate revocation list, because the trust chain itself is encapsulated in the certificate update process, thereby improving the efficiency of new certificate replacement.

[0069] It should be further explained that this design is suitable for scenarios where vehicles may be offline for extended periods (such as when parked in an underground garage). Even if the vehicle misses the certificate update window when the network is restored, as long as the old certificate has not expired, the vehicle can still use the old certificate for upgrade verification. That is, when the vehicle is back online, it can automatically obtain a new certificate to complete the replacement. Furthermore, the overlap period design between the old and new certificates avoids the certificate vacuum period caused by revoking the old certificate before issuing the new one, ensuring that the vehicle always holds at least one valid and reliable regional certificate.

[0070] This application provides an authentication method that employs a hierarchical signing architecture of global root certificate, regional certificate, and service certificate. This expands the firmware upgrade package's signature information into a three-level chain structure. The vehicle can then use its locally stored global root certificate public key to perform multi-level chain verification on the signature description file. If any level of signature fails verification, the entire trust chain is considered broken, compromising reliability. Furthermore, since firmware upgrade packages from different regions are signed by different regional certificates, the certificate chain structure in their signature description files does not match the certificate system trusted by the vehicle's pre-stored root certificate public key. Multi-level chain verification will inevitably fail due to the failure of the regional certificate verification step. This prevents the vehicle from obtaining the firmware upgrade package across regions before it can download it from another region. Compared to existing single global root certificate signing schemes (where firmware upgrade packages from all regions are signed by the same global root certificate), this method offers a more comprehensive solution. Root certificate verification cannot verify whether the vehicle has downloaded software from a different region. However, the multi-level certificate chain verification method described above can avoid this situation. At the same time, on this basis, regional control capabilities are pushed down to the signature verification level. The vehicle only needs to use the locally stored global root certificate public key to complete the corresponding chain verification, without the need for multiple real-time certificate status interactions with the cloud. This ensures that even when the vehicle is offline, it can accurately identify and reject signature description files from other regions. This makes regional isolation capabilities independent of network connection status, avoids the risks caused by multiple information interactions between the vehicle and the cloud, and avoids the possibility of forcibly refreshing the vehicle software across regions through technical means during multiple interactions. This prohibits the cross-regional deployment and installation of vehicle software upgrade packages, so that the current vehicle software upgrade technology can meet the relevant compliance requirements of intelligent connected vehicles.

[0071] Please see Figure 3 , Figure 3 This is a flowchart illustrating an authentication method provided in an embodiment of this application.

[0072] like Figure 3 As shown, authentication methods may include at least: S21. Based on the pre-stored global root certificate public key, determine whether the root certificate signature in the multi-level certificate chain signature information is valid, so as to confirm whether the regional certificate is issued by the global root certificate. In this embodiment, the vehicle extracts the global root certificate from the signature description file (it should be noted that the global root certificate carried in the signature description file is the certificate itself used for verification; the vehicle needs to compare it with the pre-stored root certificate public key, or directly use the pre-stored public key to verify its signature). At this time, the vehicle uses the global root certificate public key pre-stored in the security chip to verify the root certificate signature in the signature description file. The specific verification process is as follows: the root certificate signature is designed using the pre-stored global root certificate public key to obtain the decrypted hash value H1. At the same time, the vehicle independently calculates the hash value H2 of the regional certificate in the signature description file, and concatenates it with the regional attribute to calculate the hash H2'. H1 and H2' are compared to see if they are consistent. If they are consistent, it is confirmed that the regional certificate was indeed issued by the global root certificate, and the root certificate signature is valid.

[0073] In this embodiment, the global root certificate public key is pre-installed in the trusted execution environment or security chip on the vehicle. The public key is read from the trusted execution environment or security chip through a preset public key infrastructure interface to ensure the physical security and tamper-proof nature of the trust anchor.

[0074] It should be noted that the global root certificate public key is pre-installed in the trusted execution environment or security chip on the vehicle. The trusted execution environment is an isolated execution environment inside the vehicle's main processor, isolated from the ordinary operating system. Even if the ordinary operating system is compromised, attackers cannot access the sensitive data stored in the trusted execution environment. The security chip is an independent hardware security element with a physical anti-tampering design, which can resist physical attack methods such as voltage probing, timing attacks, and laser injection.

[0075] Specifically, during the vehicle manufacturing stage, the global root certificate public key is written once into the non-volatile storage area corresponding to the trusted security environment or security chip. The writing of this public key is usually completed by the secure programming device on the production line. After writing, it is locked and cannot be modified or read (it can only be used through the cryptographic interface). When the vehicle needs to call the global root certificate public key, it can read the public key from the trusted execution environment or security chip through the preset public key infrastructure interface.

[0076] It's important to note that this reading doesn't involve directly retrieving the raw bytes of the public key. Instead, it involves calling cryptographic operations through a secure interface. For example, vehicle software might call an interface provided by a Trusted Execution Environment (TEE). Internally, the TEE uses the stored public key to perform verification operations and returns the verification result (success / failure) to the caller without exposing the public key itself. This ensures the physical security and tamper-proof nature of the trust anchor. Even if an attacker obtains the complete software image of the vehicle, they cannot replace or extract the global root certificate public key because it is stored in a hardware-isolated area, and any modification will trigger a circuit breaker. Furthermore, since the public key itself is public information and doesn't need to be kept secret, the core objective of this storage method is to ensure its integrity (prevention of tampering), rather than confidentiality.

[0077] S22. If the root certificate signature is valid, then based on the verified regional certificate public key, determine whether the regional signature in the multi-level certificate chain signature information is valid, so as to confirm whether the service certificate was issued by the regional certificate. Furthermore, after the global root certificate signature verification is successful, the vehicle extracts the public key from the verified regional certificate and uses the public key to verify the regional signature in the signature description file. The verification process is similar, specifically including: designing to obtain the hash value H3, calculating the hash value of the service certificate and concatenating it with the regional code to calculate the hash H4, comparing whether H3 and H4 are consistent. If they are consistent, it is confirmed that the service certificate was indeed issued by the regional certificate and the regional signature is valid.

[0078] S23. If the regional signature verification is valid, then determine the validity of the regional certificate and the service certificate; Furthermore, after successful signature verification, the vehicle-side system also needs to check the validity of the regional certificate and service certificate. Specifically, this includes checking whether the current system time of the vehicle is within the valid start and end times of the certificate, and simultaneously checking whether the certificate has been revoked (this can be done by querying the local certificate revocation list, which can be distributed with the signature description file or updated through a separate channel). If the time is valid and the certificate has not been revoked, then the certificate validity is confirmed.

[0079] S24. Obtain real-time information about the current location of the vehicle and compare the area code with the real-time information. If the comparison results are consistent, the verification is successful.

[0080] Furthermore, the vehicle uses base station triangulation or an in-vehicle navigation system to locate itself and obtain real-time information about its current location. This includes determining the vehicle's current country, city, or administrative region code. Simultaneously, the vehicle extracts the regional attributes (e.g., Asia Pacific) from the regional certificate and the regional code (e.g., CN) from the service certificate from the signature description file, and compares this regional information with the vehicle's current real-time regional information. For example, if the vehicle is currently located in China and the signature description file specifies the regional code as CN, the comparison will match; if the vehicle is located in Europe but the signature description file requires CN, the comparison will fail, and the verification will fail.

[0081] It should be noted that this step effectively prevents the misuse or malicious attack of cross-regional upgrade packages. Even if an attacker steals a legitimate certificate from another region, they will not be able to successfully verify it on a vehicle in this region. Only after all the above steps (root certificate signature verification, region-level signature verification, certificate validity check, and region code comparison) have passed will the vehicle be deemed to have passed verification and allowed to proceed to the subsequent firmware download process, which greatly improves the security of firmware upgrade package installation.

[0082] In this embodiment, an authentication method is provided. Based on a pre-stored global root certificate public key, the validity of the root certificate signature in the multi-level certificate chain signature information is determined to confirm whether the regional certificate was issued by the global root certificate. If the root certificate signature is valid, the validity of the regional signature in the multi-level certificate chain signature information is determined based on the verified regional certificate public key to confirm whether the service certificate was issued by the regional certificate. If the regional signature verification is valid, the validity of the regional certificate and the service certificate is determined. Real-time information about the vehicle's current location is obtained, and the regional code is compared with the real-time information. If the comparison result is consistent, the verification is successful. That is, only after all the above steps (root certificate signature verification, regional signature verification, certificate validity check, and regional code comparison) are passed is the vehicle deemed to have passed verification and allowed to proceed to the subsequent firmware download process, greatly improving the security of firmware upgrade package installation.

[0083] Please see Figure 4 , Figure 4 This is a flowchart illustrating an authentication method provided in an embodiment of this application.

[0084] like Figure 4 As shown, authentication methods may include at least: S110. Calculate the summary information of the downloaded firmware upgrade package; S120. Based on the verified public key of the service certificate in the signature description file, determine whether the digest information matches the corresponding service-level signature, and verify the service-level signature based on the verified public key of the zone certificate in the signature description file. S130. If both verifications pass, install the firmware upgrade package.

[0085] In this embodiment, a dual verification mechanism is provided after the firmware upgrade package is downloaded to prevent the firmware from being tampered with during the download process. That is, after the vehicle completes the verification of the signature description file and downloads the firmware upgrade package, the following steps are performed: The first step is to calculate the digest information of the downloaded firmware upgrade package. The vehicle side performs a hash calculation on the downloaded firmware upgrade package binary file. The hash algorithm must be consistent with the algorithm used for the service-level signature in the signature description file. The digest value is then obtained.

[0086] The second step involves verifying the service-level signature using the service certificate's public key. The vehicle extracts the public key from the verified service certificate in the signature description file and uses this key to design the service-level signature, obtaining the original digest value encapsulated within the signature. The service-level signature also contains region code information, which the vehicle needs to extract and compare with its current region information. Then, the digest value is compared to the original digest value. If they are equal, it indicates that the firmware upgrade package was not tampered with during the download process and that the upgrade package was indeed issued by a legitimate service certificate.

[0087] The third step involves the vehicle using the regional certificate public key to verify the validity of the service certificate and reconfirm the legitimacy of the service-level signature itself. This can be achieved by verifying the integrity of the service certificate reference chain attached to the service-level signature. Alternatively, the vehicle can use the regional certificate public key to verify the revocation status and signature of the service certificate, and then use the service certificate public key to verify the service-level signature. This verifies both the matching of the service-level signature with the firmware digest (integrity) and the chain relationship between the service certificate and the regional certificate upon which the service-level signature depends (trustworthiness).

[0088] The fourth step is to install the firmware upgrade package. Only after both of the above dual verifications have passed will the vehicle flash the firmware upgrade package to the target device. This flashing process may involve steps such as the target device entering programming session mode, erasing the original firmware, writing the new firmware, verifying the integrity of the write operation, and resetting the target device. After the flashing is complete, the vehicle reports the upgrade result to the cloud server.

[0089] In this application embodiment, an authentication method is provided, which calculates the digest information of the downloaded firmware upgrade package; determines whether the digest information matches the corresponding service-level signature based on the verified service certificate public key in the signature description file, and verifies the service-level signature based on the verified region certificate public key in the signature description file; if both verifications pass, the firmware upgrade package is installed. That is, by verifying the firmware upgrade package after downloading, the method avoids the situation where problems occur when downloading the firmware upgrade package after the signature description file has been verified, thus ensuring the security and reliability of installing the firmware upgrade package.

[0090] Based on the above embodiments, specific application implementation examples are provided as follows: In this embodiment, a Merck root hash is generated for the firmware upgrade package in the cloud, and it is concatenated with the region code (such as CN, EU, NA) as the signature input. The service certificate private key is used to perform digital signature to ensure that the signature content is uniquely bound to the region attribute. The signed upgrade package includes a complete certificate chain: a global root certificate, regional certificates, and service certificates, forming a trust path that can be verified step by step. Before the upgrade, the client reads the pre-installed global root certificate public key from the secure element to verify the integrity and validity of the certificate chain, ensuring that the issuance chain has not been forged. The verification process strictly follows a chain structure: first, it verifies whether the regional certificate is issued by the global root certificate, then it verifies whether the service certificate is issued by the regional certificate to ensure the legality of the issuance level. After completing the certificate chain verification, it compares whether the regional code carried in the signature is consistent with the vehicle's current registered region. If they are inconsistent, the upgrade is terminated immediately. Finally, the public key of the service certificate is used to verify whether the signature matches the Merck root hash value and regional code of the firmware upgrade package to ensure that the firmware content has not been tampered with and that the source is trustworthy. Specifically, the software data package for the specified country or region is uploaded to the OTA cloud service platform, and a signature for the corresponding country or region is applied for from the key management system, and finally signed by a global root certificate.

[0091] It is important to note the signing details. Global root certificates only sign the signing results of countries and regions, as well as information such as country and region certificates. They do not sign the original data. The original data is signed with a dual key using country and region certificates. If there is no regional distinction between countries, the country-level certificate can be used directly for signing.

[0092] Furthermore, the key management system returns a signature result file containing: {region-level signature, country-level signature, root certificate signature, region-level certificate, country-level certificate, signature timestamp}. Note that the signature file does not contain the original data packet; therefore, when the task is published, the signature file is sent first, followed by the original data packet.

[0093] The signing file and header information (description information) are published (task publication). The content is as follows: {Data packet header{ Version number, Data packet type, length, Validity period Applicable areas Signature algorithm identifier}, Signature data { Regional certificates National-level certificate Signature result { Regional signatures National-level signature} Signature timestamp} Root certificate signing, Data checksum} The process involves receiving signature and description information at the vehicle end, calculating data verification and confirming integrity, and extracting the signature data. Then, it retrieves the global root certificate public key from the security environment via the corresponding API call, uses this public key to verify the root certificate signature, and verifies whether the national certificate was issued by the root certificate. If the national certificate is valid, it verifies whether the regional certificate was issued by the national certificate, and checks the validity (expiration time, revocation status) of both the national and regional certificates after successful verification.

[0094] Furthermore, by using the vehicle's specific registered address and location information, it is determined whether the vehicle is located within the applicable area of ​​the data packet. If it is within the applicable area, the original data packet is downloaded. After downloading, the hash value of the digest information is calculated for the original data. Subsequently, the hash calculation result of the original data is verified using the national-level certificate public key and the regional-level certificate public key. Ultimately, this achieves the verification of data integrity and the identity and applicable area of ​​the publisher.

[0095] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Figure 5 As shown, vehicle 500 may include: at least one vehicle processor 501, at least one network interface 504, user interface 503, memory 505, and at least one communication bus 502.

[0096] The communication bus 502 is used to enable communication between these components.

[0097] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0098] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0099] The vehicle processor 501 may include one or more processing cores. The vehicle processor 501 connects to various parts within the vehicle 500 via various interfaces and lines. It executes various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 505, and by calling data stored in memory 505. Optionally, the vehicle processor 501 may integrate one or more of the following: a central processing unit (CPU), a graphics processing unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the vehicle processor 501 and may be implemented as a separate chip.

[0100] The memory 505 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned vehicle processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an authentication program.

[0101] exist Figure 5 In the vehicle 500 shown, the user interface 503 is mainly used to provide an input interface for the user and to obtain the user input data; while the vehicle processor 501 can be used to call the authentication program stored in the memory 505 to specifically execute the above-mentioned related method steps to implement the authentication method provided in the above embodiment.

[0102] Furthermore, this application also protects an apparatus. This embodiment can divide the apparatus into functional modules based on the above method example. For example, each module can correspond to a separate function, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods.

[0103] When each functional module is divided according to its corresponding function, the authentication device includes: The receiving module is used to receive the signature description file issued by the cloud server. The signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate and service certificate level by level. The verification module is used to perform multi-level chain verification of the signature description file based on the pre-stored global root certificate public key; The update module is used to download the firmware upgrade package corresponding to the signature description file from the cloud server if the verification is successful, so as to update the vehicle software according to the firmware upgrade package.

[0104] Optionally, the authentication device further includes: a signature module for signing multi-level certificate chain information, including root certificate signature, zone-level signature, service-level signature, global root certificate, zone-level certificate and service certificate; Root certificate signing is obtained by signing the hash value and corresponding zone attributes of the zone certificate using the global root certificate. A region-level signature is obtained by signing the hash value of the service certificate and the corresponding region code using a region-level certificate. Service-level signatures are obtained by signing the digest information and region code of the corresponding firmware upgrade package using a service certificate.

[0105] Optionally, the verification module is also used to determine whether the root certificate signature in the multi-level certificate chain signature information is valid based on the pre-stored global root certificate public key, so as to confirm whether the regional certificate is issued by the global root certificate. If the root certificate signature is valid, then based on the verified regional certificate public key, determine whether the regional signature in the multi-level certificate chain signature information is valid, in order to confirm whether the service certificate was issued by the regional certificate. If the regional signature verification is valid, then the validity of the regional certificate and the service certificate is determined. Obtain real-time information about the vehicle's current location and compare the area code with the real-time information. If the comparison results are consistent, the verification is successful.

[0106] Optionally, the verification module is also used to pre-install the global root certificate public key in the trusted execution environment or security chip on the vehicle side, and read the public key from the trusted execution environment or security chip through a preset public key infrastructure interface to ensure the physical security and tamper-proof nature of the trust anchor.

[0107] Optionally, the authentication device further includes: an installation module for calculating a summary of the downloaded firmware upgrade package; Based on the verified public key of the service certificate in the signature description file, determine whether the digest information matches the corresponding service-level signature, and verify the service-level signature based on the verified public key of the zone certificate in the signature description file. If both verifications pass, then install the firmware upgrade package.

[0108] Optionally, the authentication device further includes: a calculation module for calculating the signature description file, which also includes description information corresponding to the multi-level certificate chain signature information, and a preset data checksum; The checksum of the description information and the signature data is calculated and compared with the data checksum. After confirming that the signature description file has not been tampered with during transmission, a multi-level chain verification is performed on the signature description file.

[0109] Optionally, the authentication device further includes an iteration module, which, if a regional certificate undergoes an iterative replacement, issues a new generation of regional certificates from the previous generation of regional certificates and verifies the trust chain by tracing upwards to the global root certificate, thereby ensuring seamless replacement of regional certificates.

[0110] It should be understood that the apparatus provided in this embodiment is used to perform the above-described authentication method, and therefore can achieve the same effect as the above-described implementation method.

[0111] When using an integrated unit, the device may include a processing module and a storage module. When the device is applied to a vehicle, the processing module can be used to control and manage the vehicle's movements. The storage module can be used to support the vehicle in executing relevant program code.

[0112] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits shown in conjunction with the disclosure of this application. The processor may also be a combination of functions that implement computing capabilities, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0113] In addition, the device provided in the embodiments of this application may specifically be a chip, component or module. The chip may include a connected processor and a memory. The memory is used to store instructions. When the processor calls and executes the instructions, the chip can execute an authentication method provided in the above embodiments.

[0114] This embodiment also provides a computer-readable storage medium storing computer program code. When the computer program code is run on a computer, the computer performs the aforementioned method steps to implement an authentication method provided in the above embodiment.

[0115] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement an authentication method provided in the above embodiment.

[0116] In this embodiment, the device, computer-readable storage medium, computer program product, or chip are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

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

[0118] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0119] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0120] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0121] In addition, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0122] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0123] In the above embodiments, 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.

[0124] The above is a description of an authentication method, apparatus, storage medium, and vehicle provided in this application. For those skilled in the art, based on the ideas of the embodiments of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An authentication method, characterized in that, The method includes: Receive a signature description file issued by a cloud server, wherein the signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate and service certificate level by level; The signature description file is verified through a multi-level chain based on the pre-stored global root certificate public key. If the verification is successful, the firmware upgrade package corresponding to the signature description file is downloaded from the cloud server to update the vehicle software according to the firmware upgrade package.

2. The method according to claim 1, characterized in that, The multi-level certificate chain signature information includes root certificate signature, zone-level signature, service-level signature, global root certificate, zone certificate, and service certificate; The root certificate signature is obtained by signing the hash value and corresponding regional attributes of the regional certificate using the global root certificate. The region-level signature is obtained by signing the hash value of the service certificate and the corresponding region code using the region-level certificate. The service-level signature is obtained by signing the digest information and the region code of the corresponding firmware upgrade package using the service certificate.

3. The method according to claim 2, characterized in that, The step of performing multi-level chain verification on the signature description file based on the pre-stored global root certificate public key includes: Based on the pre-stored global root certificate public key, determine whether the root certificate signature in the multi-level certificate chain signature information is valid, so as to confirm whether the regional certificate was issued by the global root certificate. If the root certificate signature is valid, then based on the verified regional certificate public key, determine whether the regional signature in the multi-level certificate chain signature information is valid, so as to confirm whether the service certificate is issued by the regional certificate. If the regional signature verification is valid, then the validity of the regional certificate and the service certificate is determined. Obtain real-time information about the vehicle's current location and compare the area code with the real-time information. If the comparison results are consistent, the verification is successful.

4. The method according to claim 3, characterized in that, If the verification passes, the method further includes the following steps after downloading the firmware upgrade package corresponding to the signature description file from the cloud server: Calculate the summary information of the downloaded firmware upgrade package; Based on the verified public key of the service certificate in the signature description file, determine whether the digest information matches the corresponding service-level signature, and verify the service-level signature based on the verified public key of the region certificate in the signature description file. If both verifications pass, then install the firmware upgrade package.

5. The method according to claim 3, characterized in that, The global root certificate public key is pre-installed in the trusted execution environment or security chip on the vehicle. The public key is read from the trusted execution environment or security chip through a preset public key infrastructure interface to ensure the physical security and tamper-proof nature of the trust anchor.

6. The method according to claim 1, characterized in that, Before the step of performing multi-level chain verification on the signature description file based on the pre-stored global root certificate public key, the method further includes: The signature description file also includes description information corresponding to the multi-level certificate chain signature information, as well as a preset data checksum; The checksum of the description information and the signature data is calculated and compared with the data checksum to perform multi-level chain verification on the signature description file after confirming that the signature description file has not been tampered with during transmission.

7. The method according to claim 1, characterized in that, If the verification passes, the method further includes the following steps after downloading the firmware upgrade package corresponding to the signature description file from the cloud server: If the regional certificate is replaced, the new generation of regional certificate is issued by the previous generation regional certificate, and the trust chain is verified by tracing back to the global root certificate level by level to ensure the seamless rotation of the regional certificate.

8. An authentication device, characterized in that, The device includes: The receiving module is used to receive a signature description file sent by the cloud server. The signature description file includes multi-level certificate chain signature information, which is obtained by signing the global root certificate, regional certificate and service certificate level by level. The verification module is used to perform multi-level chain verification on the signature description file based on the pre-stored global root certificate public key; The update module is used to download the firmware upgrade package corresponding to the signature description file from the cloud server if the verification is successful, so as to update the vehicle software according to the firmware upgrade package.

9. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method as described in any one of claims 1 to 7.

Images