Information processing method, information processing device, and computer-readable medium

Abstract

Embodiments of the present disclosure provide an information processing method, an information processing device, and a computer readable storage medium. An information processing method includes receiving, at an electronic device of a vehicle, an executable file from an executable file management device, the executable file being signed based on a vehicle digital certificate of the vehicle. The method also includes verifying the executable file based on the vehicle digital certificate to determine a security of the executable file. The method further includes executing the executable file on the electronic device if the executable file is determined to be secure. Embodiments of the present disclosure improve the security of executing an executable file on an electronic device of a vehicle.

Description

Technical Field

[0001] The embodiments disclosed herein relate generally to the technical fields of information processing and information security, and more specifically to information processing methods, information processing apparatus, and computer-readable media. Background Technology

[0002] To meet the application services, connected car services, and entertainment needs of vehicle occupants in different scenarios, applications developed by third parties other than the vehicle manufacturer or owner can be installed on the vehicle's in-vehicle electronic devices (e.g., in-vehicle infotainment systems). However, running third-party application installers or other executable files on in-vehicle electronic devices also poses challenges to the system security of these devices. Summary of the Invention

[0003] The embodiments of this disclosure propose a technical solution for verifying executable files used to execute on electronic devices in a vehicle based on a vehicle digital certificate. More specifically, the embodiments of this disclosure provide an information processing method, an information processing apparatus, and a computer-readable medium.

[0004] In a first aspect of this disclosure, an information processing method is provided. The method includes: receiving an executable file from an executable file management device at an electronic device in a vehicle, the executable file being signed based on a vehicle digital certificate. The method further includes: verifying the executable file based on the vehicle digital certificate to determine the security of the executable file. The method further includes: if the executable file is determined to be secure, executing the executable file on the electronic device.

[0005] In a second aspect of this disclosure, an information processing method is provided. The method includes: generating a vehicle digital certificate for a vehicle based on vehicle information at a certificate management device. The method further includes: receiving a raw executable file, which will be executed on an electronic device of the vehicle, from an executable file management device. The method further includes: signing the raw executable file based on the vehicle digital certificate to generate an executable file for transmission to an electronic device. The method further includes: transmitting the executable file to the executable file management device.

[0006] In a third aspect of this disclosure, an information processing method is provided. The method includes: at an executable file management device, if it is determined that an original executable file will be provided to an electronic device of a vehicle, sending the original executable file to a certificate management device. The method further includes: receiving from the certificate management device the executable file for sending to the electronic device, the executable file being signed based on a vehicle digital certificate of the vehicle. The method further includes: sending the executable file to the electronic device.

[0007] In a fourth aspect of this disclosure, an information processing apparatus is provided. The apparatus includes at least one processing unit and at least one memory. The at least one memory is coupled to the at least one processing unit and stores instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the apparatus to perform actions. These actions include: receiving an executable file from an executable file management device at an electronic device of a vehicle, the executable file being signed based on a vehicle digital certificate. The actions also include: verifying the executable file based on the vehicle digital certificate to determine the security of the executable file. The actions further include: if the executable file is determined to be secure, executing the executable file on the electronic device.

[0008] In a fifth aspect of this disclosure, an information processing apparatus is provided. The apparatus includes at least one processing unit and at least one memory. The at least one memory is coupled to the at least one processing unit and stores instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the apparatus to perform actions. These actions include: generating a vehicle digital certificate for a vehicle based on vehicle information at a certificate management device. The actions also include: receiving a raw executable file from an executable file management device, which will be executed on an electronic device in the vehicle. The actions further include: signing the raw executable file based on the vehicle digital certificate to generate an executable file for transmission to an electronic device. The actions further include: transmitting the executable file to the executable file management device.

[0009] In a sixth aspect of this disclosure, an information processing apparatus is provided. The apparatus includes at least one processing unit and at least one memory. The at least one memory is coupled to the at least one processing unit and stores instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the apparatus to perform actions. These actions include: at an executable file management device, if it is determined that an original executable file will be provided to an electronic device of a vehicle, sending the original executable file to a certificate management device. The actions also include: receiving from the certificate management device the executable file for transmission to the electronic device, the executable file being signed based on a vehicle digital certificate of the vehicle. The actions further include: transmitting the executable file to the electronic device.

[0010] In a seventh aspect of this disclosure, a computer-readable storage medium is provided. A computer program is stored on the computer-readable storage medium, which, when executed by a device, causes the device to perform the method according to the first aspect.

[0011] In an eighth aspect of this disclosure, a computer-readable storage medium is provided. A computer program is stored on the computer-readable storage medium, which, when executed by a device, causes the device to perform the method according to the second aspect.

[0012] In a ninth aspect of this disclosure, a computer-readable storage medium is provided. A computer program is stored on the computer-readable storage medium, which, when executed by a device, causes the device to perform the method according to the third aspect.

[0013] It should be understood that the content described in this summary section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0014] The above and other objects, features, and advantages of embodiments of the present disclosure will become readily apparent from the following detailed description taken in conjunction with the accompanying drawings. Several embodiments of the present disclosure are illustrated in the drawings by way of example and not limitation.

[0015] Figure 1 A schematic diagram of an example environment in which embodiments of the present disclosure may be implemented is shown.

[0016] Figure 2 An example interaction process between an electronic device, a certificate management device, and an executable file management device in a vehicle, according to an embodiment of the present disclosure, is illustrated.

[0017] Figure 3 An example interaction process is illustrated between an electronic device in a vehicle, a secure storage area of ​​the electronic device, a certificate management device, an executable file management device, and an application developer device, according to an embodiment of the present disclosure.

[0018] Figure 4 A flowchart illustrating an example process of an information processing method performed at an electronic device in a vehicle according to an embodiment of the present disclosure is shown.

[0019] Figure 5 A flowchart illustrating an example process of an information processing method performed at a certificate management device according to an embodiment of the present disclosure is shown.

[0020] Figure 6 A flowchart illustrating an example process of an information processing method executed at an executable file management device according to an embodiment of the present disclosure is shown.

[0021] Figure 7 A block diagram of an example device that can be used to implement embodiments of the present disclosure is shown.

[0022] Throughout all the accompanying drawings, the same or similar reference numerals are used to denote the same or similar components. Detailed Implementation

[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure may be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide the reader with a more thorough and complete understanding of this disclosure. Therefore, it should be understood that the drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0024] As mentioned above, running third-party application installers or other executable files on in-vehicle electronic devices poses challenges to the system security of these devices. This challenge places higher demands on the system developers of in-vehicle electronic devices from a security perspective. More specifically, among the various aspects of ensuring the system security of in-vehicle electronic devices, a crucial step may be the system verification process for application installers (or other executable files). If the in-vehicle electronic device can implement a higher level of security verification process for third-party executable files, it could be advantageous in ensuring the security of the executable files. For example, assuming the in-vehicle electronic device can use vehicle-specific security verification methods to verify executable files intended for installation in the vehicle, it can better determine whether the executable files are secure.

[0025] However, in conventional verification methods for application installers or installation files, third-party application developers typically use their own self-issued digital certificates to sign the application installation files they develop. The signed installation files can then be provided to in-vehicle electronic devices. Before running the installation files, the in-vehicle electronic devices can use the digital certificate provided by the application developer to verify the digital signature of the installation files. If the verification passes, the in-vehicle electronic devices will run the application installation files.

[0026] As seen from the above conventional verification methods, the application installer or installation file is signed by the third-party developer using their own digital certificate. This allows the in-vehicle electronic device to verify the integrity of the installation file, preventing it from being tampered with or replaced during transmission. Furthermore, during subsequent application upgrades or replacements, the third-party developer's digital certificate can serve as an identity verification identifier. For example, if the in-vehicle electronic device verifies that the digital certificate of the developer providing the updated or replaced version of the application installation file matches the digital certificate of the developer providing the previous version, the device can determine that the developers providing both versions are the same, and can then proceed with the application upgrade or replacement.

[0027] However, the inventors of this application discovered through research and analysis that the aforementioned conventional verification methods cannot ensure the security of application installation files developed by application developers. Furthermore, conventional verification methods cannot provide unified management of application developers and may contain vulnerabilities that allow application developers to illegally obtain vehicle privacy information. For example, when an in-vehicle electronic device executes an application installation file developed by a third-party application developer for the first time, the in-vehicle electronic device cannot verify the third-party developer's digital certificate or identity and can only completely trust the third-party developer's digital certificate. As another example, since the application developer's digital certificate is provided by the application developer themselves, the vehicle manufacturer or owner cannot effectively manage various application installation files and individual application developers for specific vehicles, thus creating security risks. In extreme cases, such security risks could lead to application developers illegally obtaining vehicle privacy information.

[0028] In view of the aforementioned problems and other potential issues in traditional solutions, embodiments of this disclosure propose a technical solution for verifying executable files intended for execution on a vehicle's electronic device based on a vehicle digital certificate. Specifically, in one aspect, the vehicle's electronic device receives an executable file from an executable file management device, the executable file being signed based on the vehicle's digital certificate. Furthermore, the vehicle's electronic device verifies the executable file based on the vehicle digital certificate to determine its security. Then, if the vehicle's electronic device determines that the executable file is secure, it executes the executable file on the electronic device.

[0029] On the other hand, at the certificate management device, a vehicle digital certificate is generated based on the vehicle's information. Additionally, the certificate management device receives a raw executable file from the executable file management device, which will be executed on the vehicle's electronic devices. The certificate management device then signs the raw executable file based on the vehicle digital certificate to generate an executable file for transmission to the vehicle's electronic devices. Finally, the certificate management device sends the executable file to the executable file management device.

[0030] On the other hand, at the executable file management device, if it is determined that the original executable file will be provided to the vehicle's electronic devices, the original executable file is sent to the certificate management device. Then, the executable file management device receives the executable file from the certificate management device for sending to the vehicle's electronic devices; the executable file is signed based on the vehicle's digital certificate. Next, the executable file management device sends the executable file to the vehicle's electronic devices.

[0031] Through embodiments of this disclosure, a certificate management device can sign executable files based on each vehicle's digital certificate (e.g., which may contain vehicle-related information). This adds a validity check of the vehicle digital certificate to the executable file, building upon the developer's digital signature used by the application developer. This prevents executable files from being executed on the vehicle's electronic devices by unknown developers. For example, because the vehicle has a vehicle digital certificate, the executable file can only be executed on the vehicle's electronic devices after passing verification based on the vehicle digital certificate or the certificate chain (or trust chain) associated with the vehicle digital certificate. If the executable file fails such verification, it can be considered an illegitimate executable file, thereby preventing unknown executable files from executing on the vehicle's electronic devices. Thus, the security of executable files can be enhanced through the vehicle digital certificate.

[0032] In contrast, conventional verification methods only eliminate the need to consider application installation security issues if third-party developers are prohibited from creating application installation files for in-vehicle electronic devices—that is, the vehicle system is entirely closed-source and does not integrate third-party application services. Furthermore, compared to conventional vehicle communication encryption processes, embodiments of this disclosure generate vehicle digital certificates using vehicle information. These vehicle digital certificates correspond to asymmetric encryption algorithms, rather than the symmetric algorithms typically used in vehicle communication encryption. Moreover, embodiments of this disclosure can utilize the vehicle digital certificate as a root certificate issuance mechanism, thereby ensuring the legitimacy of the vehicle digital certificate. Therefore, embodiments of this disclosure, based on the legitimacy of the vehicle digital certificate, guarantee the legitimacy and security of executable files (e.g., binary programs) installed on vehicle electronic devices.

[0033] More specifically, through the embodiments of this disclosure, when an in-vehicle electronic device executes an application installation file developed by a third-party application developer for the first time, since the application installation file is signed with the vehicle's digital certificate, the in-vehicle electronic device can verify whether the application installation file has been signed based on the vehicle's digital certificate and has not been tampered with, thereby determining the security of the application installation file without relying on verifying the third-party developer's own digital certificate. For example, a certificate management device can uniformly issue and manage vehicle digital certificates and / or application developer digital certificates, so vehicle manufacturers or owners can effectively manage various application installation files and application developers for specific vehicles, thereby eliminating potential security risks and the possibility of application developers illegally obtaining vehicle private information. In summary, the embodiments of this disclosure improve the security of executing executable files on in-vehicle electronic devices.

[0034] Figure 1A schematic diagram of an example environment 100 in which embodiments of the present disclosure may be implemented is shown. In example environment 100, vehicle 105 may include in-vehicle electronic equipment 110 that is fixedly or non-fixedly disposed within vehicle 105. In the context of this disclosure, in-vehicle electronic equipment 110 may also be referred to as electronic equipment 110 of vehicle 105. In some embodiments, in-vehicle electronic equipment 110 may include a processor or controller for processing various information and data related to in-vehicle electronic equipment 110 and for controlling various operations and functions of in-vehicle electronic equipment 110, etc. In some embodiments, in-vehicle electronic equipment 110 may be an electronic device dedicated to being disposed on and used in vehicle 105, such as a head unit or in-vehicle tablet computer of vehicle 105. In other embodiments, in-vehicle electronic equipment 110 may also be an electronic device carried to vehicle 105 by occupants of vehicle 105 and temporarily used in vehicle 105, such as an occupant's mobile phone, tablet computer, etc. In further embodiments, in-vehicle electronic equipment 110 may also be any other electronic device associated with vehicle 105.

[0035] Under the control of a processor or controller, the in-vehicle electronic device 110 can perform a variety of functions or operations. For example, the functions or operations of the in-vehicle electronic device 110 may include, but are not limited to, browsing web pages, voice interaction, playing multimedia content, playing radio content, providing point-of-interest (PoI) search functionality, providing navigation information, making phone calls, running in-vehicle games, and any other known or future-developed functions or operations. In some embodiments, the in-vehicle electronic device 110 may have or be able to access a secure storage area 115. As used herein, a secure storage area 115 may refer to a storage area with a higher level of security or protection than a typical storage area, which may be used to store sensitive information, privacy information, other important information, etc., related to the vehicle 105. For example, such information may include the vehicle digital certificate 125 of the vehicle 105, certificate chain information associated with the vehicle digital certificate 125, any other important information about the vehicle 105, etc. In some embodiments, the electronic device 110 may need to provide a password or require high access privileges when accessing or retrieving data or content stored in the secure storage area 115, etc.

[0036] It should be noted that, although Figure 1 The secure storage area 115 is shown as being external to the electronic device 110, but this is merely illustrative and not intended to limit the scope of this disclosure in any way. In other embodiments, the secure storage area 115 may also be located internally to the electronic device 110. It should also be noted that... Figure 1In the illustrated example scenario, if vehicle 105 or electronic device 110 includes a secure storage area 115 for storing vehicle digital certificates 125, then Figure 1 The description shows that electronic device 110 has obtained vehicle digital certificate 125 from secure storage area 115, for example, for subsequent verification 135 against executable files. In some embodiments, vehicle 105 or electronic device 110 may also not include secure storage area 115. In such a case, Figure 1 The electronic device 110 is described as having a vehicle digital certificate 125.

[0037] like Figure 1 As shown, example environment 100 also includes certificate management device 120. As used herein, certificate management device 120 can generally refer to any device that manages digital certificates (such as vehicle digital certificates, application developer digital certificates, etc.), such as a computer or server used to manage various digital certificates. In some embodiments, certificate management device 120 can be a certificate management device of a certificate authority (also referred to as a digital certificate authority, certificate issuer, etc.). For example, certificate management device 120 can be a certificate management device owned by the manufacturer of vehicle 105 as the certificate authority. In the context of this disclosure, certificate management device 120 can also be referred to as a certificate center or original equipment manufacturer (OEM) certificate center, etc.

[0038] As used in this article, a "signature" or "digital signature" (also known as a public-key digital signature, electronic seal, etc.) is a method for verifying digital information using techniques in the field of public-key cryptography. Generally, a digital signature typically defines two complementary encryption and decryption operations, where the encryption operation is used for signing and the decryption operation is used for verification. Typically, a digital signature is a string of numbers or codes that only the sender of the information can generate and that cannot be forged by others. This string of numbers also serves as valid proof of the authenticity of the information sent by the sender. For example, a digital signature is an application of asymmetric key encryption technology and digital digest technology.

[0039] As used in this article, a "digital certificate" is generally a string of numbers or codes used in communications (e.g., internet communications) to identify the identities of the parties involved. Digital certificates can be issued by digital certificate authorities. A digital certificate may contain information such as the certificate issuer's public key, the name of the public key holder (certificate issuer name), the digital signature of the digital certificate authority, the validity period, the name of the authorization center, the certificate serial number, and the signature algorithm used by the certificate. Generally speaking, a digital certificate can be understood as an individual's or company's online identity card. In other words, a digital certificate is an electronic document issued by a trusted third party to prove the identity of the owner of information or data and to prove the owner's public key signature.

[0040] Therefore, applying encryption technology in the use of digital certificates can achieve authentication, confidentiality, integrity, and non-repudiation of information or data. Authentication means that the two parties transmitting information on the network cannot meet in person; digital certificates can verify their identities, preventing impersonation. Confidentiality means that by encrypting information with digital certificates, only the recipient can read the encrypted information, thus ensuring that the information cannot be stolen. Integrity means that digital certificates can verify whether the transmitted information has been tampered with or lost during transmission. Non-repudiation means that digital certificates can be used for digital signatures, accurately identifying the signer and verifying the signature content; therefore, the signer has non-repudiation of the signature and its content, similar to a handwritten signature and having the same effect.

[0041] exist Figure 1 In the depicted example, certificate management device 120 can generate and manage a vehicle digital certificate 125 for vehicle 105 based on information from vehicle 105. Specifically, certificate management device 120 can generate and manage the vehicle digital certificate 125, which includes a public key, and generate and manage a private key corresponding to or matching the vehicle digital certificate 125. Generally, the private key corresponding to the vehicle digital certificate 125 can be used to sign data or information provided to vehicle 105, for example, to sign an original executable file from executable file management device 130 to generate executable file 135. On the other hand, the vehicle digital certificate 125, including the public key, can be provided to electronic device 110 or other devices of vehicle 105 for verifying any data or information signed based on the vehicle digital certificate 125 (e.g., its corresponding private key), for example, to verify the security of executable file 135 signed using the private key.

[0042] In some embodiments, the information of vehicle 105 used to generate vehicle digital certificate 125 may include a unique identifier for vehicle 105. In this way, vehicle digital certificate 125 generated based on the unique identifier of vehicle 105 is unique and exclusive to vehicle 105, thereby further enhancing the security of data or information signed based on vehicle digital certificate 125. Therefore, in such embodiments, in addition to having the functions and roles typically possessed by digital certificates, vehicle digital certificate 125 differs from ordinary digital certificates in that vehicle digital certificate 125 is specific to vehicle 105 or unique to vehicle 105. In other words, for each different vehicle, certificate management device 120 can generate and manage a unique vehicle digital certificate. For example, in some embodiments, the unique identifier of vehicle 105 used to generate vehicle digital certificate 125 may be a unique Vehicle Identification Number (VIN) or Vehicle Identifier (VID) for vehicle 105.

[0043] like Figure 1 As shown, example environment 100 also includes executable file management device 130. As used herein, executable file management device 130 can generally refer to any device that manages executable files, such as a computer or server for managing executable files. As used herein, an executable file is a file that can be loaded and executed by the operating system of a device. The presentation of executable files can vary depending on the operating system environment. In some embodiments, an executable file may include an application installation file, such as an APK file in the Android system. When the executable file is an application installation file, executable file management device 130 may also be referred to as an application center, application store, OEM app store, OEM app center, etc. Figure 1 In the illustrated example, executable file management device 130 can manage executable file 135. For example, electronic device 110 of vehicle 105 can obtain executable file 135 from executable file management device 130 in order to install the corresponding application on electronic device 110.

[0044] In some embodiments, executable file 135 may be signed based on vehicle digital certificate 125 (e.g., its corresponding private key) of vehicle 105. For example, executable file management device 130 may provide the original executable file to certificate management device 120. Certificate management device 120 may sign the original executable file based on vehicle digital certificate 125 (e.g., its corresponding private key) to obtain executable file 135. Then, certificate management device 120 may return executable file 135 to executable file management device 130. As mentioned above, in some embodiments, certificate management device 120 may generate and manage a unique vehicle digital certificate for each different vehicle. That is, different vehicles may have different vehicle digital certificates, so signing executable files based on different vehicle digital certificates can generate different (signed) executable files. In contrast, conventional executable files are the same for different vehicles. Therefore, in some embodiments, unlike conventional executables, executables 135 signed with vehicle digital certificate 125 of vehicle 105 can be ensured to be installed only on electronic devices 110 of vehicle 105, thereby improving the data security of executable 135.

[0045] like Figure 1As shown, in some embodiments, example environment 100 may further include application developer device 140. As used herein, application developer device 140 may generally refer to any device of an application developer (e.g., a vehicle infotainment application developer), such as a computer or server used for developing or managing application installers. In some embodiments, application developer device 140 may provide an original executable file (e.g., an application installation file) to executable file management device 130 so that the executable file 135, signed based on vehicle digital certificate 125, is ultimately provided to the electronic devices 110 of vehicle 105 for execution after verification. In some embodiments, application developer device 140 may apply to certificate management device 120 for the issuance of a developer digital certificate. After obtaining the developer digital certificate, application developer device 140 may sign the developed application installation file based on the developer digital certificate to indicate that the application developer corresponding to application developer device 140 is a legitimate and secure application developer verified by certificate management device 120.

[0046] In some embodiments, the electronic devices 110 of vehicle 105 can be controlled and managed by the owner of vehicle 105, the certificate management device 120 and the executable file management device 130 can be controlled and managed by the same operator (e.g., the manufacturer of vehicle 105), and the application developer device 140 can be controlled and managed by a third-party application developer. Of course, in other embodiments, the application developer device 140 may also belong to the same operator as the certificate management device 120 and the executable file management device 130, such as the manufacturer of vehicle 105. In other embodiments, the electronic devices 110 of vehicle 105 can also be controlled or managed by the operator of the certificate management device 120 and the executable file management device 130 (e.g., the manufacturer of vehicle 105). For example, this could be a situation where, during the production process of vehicle 105, the manufacturer of vehicle 105 executes an executable file (e.g., installs an application) on the electronic devices 110 of vehicle 105.

[0047] In some embodiments, since the certificate management device 120 can be controlled and managed by the manufacturer of the vehicle 105, the electronic devices 110 of the vehicle 105 can fully trust the vehicle digital certificate 125 generated by the certificate management device 120, thereby fundamentally solving the trustworthiness problem of the vehicle digital certificate 125. Furthermore, since the certificate management device 120 can belong to the manufacturer of the vehicle 105, it can easily obtain or know the unique identifier of the vehicle 105, such as the vehicle 105's VIN or VID code. In some embodiments, if the certificate management device 120 and the executable file management device 130 are controlled and managed by the same operator, then the certificate management device 120 and the executable file management device 130 can be implemented as two different services on the same computer or server, instead of implementing the certificate management device 120 and the executable file management device 130 as two separate computers or servers.

[0048] In some embodiments, electronic device 110, certificate management device 120, executable file management device 130, and application developer device 140 may include any device capable of implementing computing and / or control functions. This can be any type of fixed computing device, mobile computing device, or portable computing device, including but not limited to dedicated computers, general-purpose computers, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, multimedia computers, mobile phones, general-purpose processors, microprocessors, microcontrollers, or state machines. Electronic device 110, certificate management device 120, executable file management device 130, and application developer device 140 may be implemented as individual computing devices or combinations of computing devices, such as a combination of a digital signal processor (DSP) and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0049] Although vehicle 105 is Figure 1 While the vehicle 105 is depicted as a car, embodiments of this disclosure are not limited to this, but are equally applicable to any vehicle that may be equipped with onboard electronic equipment. For example, vehicle 105 can be any suitable motor vehicle or non-motor vehicle, examples of which include, but are not limited to, cars, sedans, trucks, buses, electric vehicles, motorcycles, bicycles, etc. More generally, embodiments of this disclosure can also be applied to any means of transport equipped with onboard electronic equipment. For example, a means of transport can refer to any type of vehicle capable of carrying people and / or goods and being mobile, such as vehicles, boats, trains, airplanes, etc.

[0050] Furthermore, it should be understood that Figure 1The devices, objects, units, elements, or components shown are merely illustrative and are relevant to embodiments of this disclosure. In practice, example environment 100 may also include other devices, objects, units, elements, or components, etc. Additionally, Figure 1 The specific number of devices, objects, units, elements, or components shown is merely illustrative and is not intended to limit the scope of this disclosure in any way. In other embodiments, example environment 100 may include any suitable number of devices, objects, units, elements, or components, etc. Furthermore, Figure 1 The specific location of the electronic device 110 within the vehicle 105 depicted is merely illustrative and is not intended to limit the scope of this disclosure in any way. In other embodiments, the electronic device 110 may be disposed or placed in any suitable location within the vehicle 105. Therefore, embodiments of this disclosure are not limited to those described herein. Figure 1 It does not describe a specific scenario, but rather applies generally to any technological environment in which a vehicle carries electronic equipment.

[0051] Figure 2 An example interaction process 200 between electronic devices 110, certificate management devices 120, and executable file management devices 130 in vehicle 105 according to an embodiment of the present disclosure is illustrated. For purposes of discussion, reference will be made below. Figure 1 The example interaction process 200 is described below. However, it should be understood that the example interaction process 200 can also be applied to any other scenario where the security of executable files is ensured based on vehicle digital certificates so that they can run on in-vehicle electronic devices.

[0052] like Figure 2As shown, the certificate management device 120 can generate (202) a vehicle digital certificate 125 for vehicle 105 based on information about vehicle 105. For example, when generating the vehicle digital certificate 125, in addition to the various information that a digital certificate generally needs to include, the certificate management device 120 can also include relevant information about vehicle 105 in the vehicle digital certificate 125, so that the vehicle digital certificate 125 is associated with vehicle 105 or generated for vehicle 105. Generally, the information about vehicle 105 used to generate the vehicle digital certificate 125 can include any information related to vehicle 105. For example, such information may include, but is not limited to, one or more of the following: country or region code of origin, manufacturer code, vehicle model code, engine type code, body and chassis series code, model year, final assembly plant code, serial number, etc. In some embodiments, to further improve the security of the vehicle digital certificate 125, the certificate management device 120 can generate the vehicle digital certificate 125 based on the unique identifier of vehicle 105. In other words, the unique identifier of vehicle 105 is unique and exclusive to vehicle 105, and therefore the vehicle digital certificate 125 generated based on the unique identifier is also unique and exclusive to vehicle 105. In this way, the security of data or information (e.g., executable files) signed based on the vehicle digital certificate 125 can be further improved. In some embodiments, for each different vehicle that requires the generation of a vehicle digital certificate at the certificate management device 120, the certificate management device 120 can specifically generate or assign a unique identifier to identify that vehicle. In this way, the certificate management device 120 can flexibly set unique identifiers for vehicles itself without having to obtain the unique identifier of vehicle 105 from other devices or information sources.

[0053] In some embodiments, the unique identifier of vehicle 105 may include the Vehicle Identification Number (VIN) of vehicle 105. The Vehicle Identification Number, also known as the Vehicle Identification Number, "Vehicle Identification Number," or "Frame Number," can be considered equivalent to a car's or vehicle's "identity card." Simply put, the Vehicle Identification Number (VIN) is a code assigned to a vehicle by the vehicle manufacturer to identify a specific vehicle. Generally, the Vehicle Identification Number (VIN) can consist of 17 alphanumeric characters. Through the Vehicle Identification Number (VIN), one can learn about a car's manufacturer, brand, vehicle characteristics, and other information. By using the Vehicle Identification Number (VIN) of vehicle 105 as the unique identifier to generate the vehicle digital certificate 125, since the Vehicle Identification Number (VIN) is unique to each vehicle, it can be ensured that the vehicle identifier used to generate the vehicle digital certificate 125 is a "unique" identifier. On the other hand, since the existing Vehicle Identification Number (VIN) of vehicle 105 is used to generate the vehicle digital certificate 125, the burden of certificate management device 120 generating and managing different unique identifiers for different vehicles for generating vehicle digital certificates is avoided. In other embodiments, the unique identifier of vehicle 105 used to generate vehicle digital certificate 125 may also include vehicle identifier code (VID) of vehicle 105. Typically, compared to vehicle identification number (VIN), vehicle identifier code (VID) can be a relatively open or public unique identifier for a vehicle, while vehicle identification number (VIN) is relatively private or sensitive because it contains a lot of vehicle information.

[0054] At the executable file management device 130, if the executable file management device 130 determines (204) that a certain original executable file 207 under its management is to be provided to the electronic device 110 of the vehicle 105 (e.g., for installation on the electronic device 110), the executable file management device 130 may send (206) the original executable file 207 to the certificate management device 120 so that the certificate management device 120 may sign the original executable file 207 based on the vehicle digital certificate 125. In some embodiments, the executable file management device 130 may send all the executable files under its management sequentially or together to the certificate management device 120 so that the certificate management device 120 may sign all the executable files based on the vehicle digital certificate 125. In this way, when electronic device 110 requests an executable file from executable file management device 130, executable file management device 130 can directly send the signed executable file to electronic device 110 without temporarily sending the requested original executable file to certificate management device 120 for signing, thereby shortening the time delay for electronic device 110 to obtain executable file 135.

[0055] In other embodiments, the executable file management device 130 may send the requested executable file to the certificate management device 120 for signing based on the request for the executable file from the electronic device 110. That is, if the executable file management device 130 determines that it has received a request for the original executable file 207 from the electronic device 110, the executable file management device 130 can determine that the original executable file 207 will be provided to the electronic device 110, and thus send the original executable file 207 to the certificate management device 120 (206). In this way, the executable file management device 130 does not need to send all the executable files it manages to the certificate management device 120 for signing, but selectively sends the executable files that the electronic device 110 needs to execute to the certificate management device 120 for signing, thereby simplifying the related operations of the certificate management device 120 and the executable file management device 130 and saving transmission resources between the two.

[0056] It should be noted that the executable file management device 130 can obtain the original executable file 207 through any suitable means. For example, the original executable file 207 (e.g., an application installation file) can be created or developed by the administrator of the executable file management device 130. Therefore, the administrator of the executable file management device 130 can store the created or developed original executable file 207 at the executable file management device 130 for management purposes. In other embodiments, the executable file management device 130 can obtain the original executable file 207 from the application developer device 140. In other words, the original executable file 207 can be created or developed by another party, namely the administrator of the application developer device 140, who is different from the administrator of the executable file management device 130. In such a case, the administrator of the application developer device 140 can provide the original executable file 207 to the executable file management device 130 through the application developer device 140 for unified management.

[0057] In some embodiments, to enhance the authentication of the application developer device 140 and improve the data security of the original executable file 207, the certificate management device 120 can issue a developer digital certificate to the application developer. The application developer device 140 can sign the developed executable file based on the developer digital certificate, and the executable file management device 130 can verify the identity of the application developer corresponding to the application developer 140 based on the developer digital certificate. Specifically, if the certificate management device 120 determines that it has received a request for a developer digital certificate from the application developer device 140, the certificate management device 120 can generate a developer digital certificate based on the application developer's information. In other words, the generated developer digital certificate is specific to the application developer and is used to verify the identity of the application developer. Then, the certificate management device 120 can send the developer digital certificate to the application developer device 140 for signing the developed executable file. In this way, in addition to the vehicle digital certificate 125 of vehicle 105, certificate management device 120 can also generate developer digital certificates for the application developer corresponding to application developer device 140 to verify the identity of the application developer, thereby further improving the data security of original executable file 207 and executable file 135.

[0058] When using a developer digital certificate, the application developer corresponding to application developer device 140 can use the private key corresponding to the developer digital certificate to sign the developed executable file, thereby generating an original executable file 207, which is then sent to executable file management device 130. Therefore, executable file management device 130 can receive the original executable file 207 from application developer device 140, and the original executable file 207 is signed based on the application developer's developer digital certificate. Next, executable file management device 130 can verify the original executable file 207 based on the developer digital certificate (e.g., a public key) to determine whether the application developer corresponding to application developer device 140 is a legitimate and secure developer certified by certificate management device 120. In this way, before finally sending the executable file to electronic device 110 of vehicle 105, executable file management device 130 can first verify the legitimate identity of the application developer providing the original executable file 207 based on the developer digital certificate, thereby improving the information security of the original executable file 207.

[0059] At the certificate management device 120, the certificate management device 120 can receive (208) a raw executable file 207 that will be executed on the electronic device 110 of the vehicle 105 from the executable file management device 130. The certificate management device 120 can then sign (210) the raw executable file 207 based on the vehicle digital certificate 125 to generate an executable file 135 for transmission to the electronic device 110. For example, the certificate management device 120 can sign the raw executable file 207 using a private key matching the vehicle digital certificate 125 to generate the executable file 135. In some embodiments, the executable file 135 may include an application installation file, such as an apk file in the Android system. In this way, the vehicle digital certificate 125, generated based on information from the vehicle 105, can be applied to verify the application installation file, thereby ensuring the security of the application installation file. This allows the electronic device 110 of the vehicle 105 to securely install various application installation files, thus eliminating the risk of installing malicious or illegal application installation files while allowing the electronic device 110 to access the convenient functions and services provided by various applications.

[0060] In some embodiments, to reduce the potential risks arising from directly signing the vehicle digital certificate 125 as the root certificate, the certificate management device 120 may not directly use the vehicle digital certificate 125 as the root certificate to sign the executable file 135. Instead, it may use an intermediate certificate based on the vehicle digital certificate 125 to sign the executable file 135. In this case, when signing the original executable file 207 based on the vehicle digital certificate 125, the certificate management device 120 may first generate an intermediate certificate based on the vehicle digital certificate 125. For example, the generated intermediate certificate may be based on the vehicle digital certificate 125 as the root certificate and one or more levels of intermediate certificates, thereby forming a "certificate chain". Then, the certificate management device 120 may use the intermediate certificate to sign the original executable file 207. In this case, the electronic device 110 of the vehicle 105 may verify the executable file 207 based on the "certificate chain" with the vehicle digital certificate 125 as the root certificate. In this way, the certificate management device 120 can ensure the information security of the executable file 135 by signing the intermediate certificate, while also avoiding the potential risks caused by directly using the vehicle digital certificate 125 as the root certificate to sign the original executable file 207.

[0061] Next, the certificate management device 120 can send (212) the executable file 135 to the executable file management device 130. Correspondingly, the executable file management device 130 can receive (214) the executable file 135 from the certificate management device 120 for sending to the electronic device 110. It should be noted that the executable file 135 here is signed based on the vehicle digital certificate 125 of the vehicle 105. After receiving (214) the executable file 135, the executable file management device 130 can send (216) the executable file 135 to the electronic device 110 of the vehicle 105. Correspondingly, the electronic device 110 of the vehicle 105 can receive (218) the executable file 135 from the executable file management device 130.

[0062] Upon receiving (218) the executable file 135, the electronic device 110 can verify (220) the executable file 135 based on the vehicle digital certificate 125 to determine the security of the executable file 135. As described above, in some embodiments, the original executable file 207 can be directly signed using the vehicle digital certificate 125 as the root certificate, for example, by directly signing it using the private key that matches the vehicle digital certificate 125. In such a case, the electronic device 110 can directly use the vehicle digital certificate 125 (e.g., the public key) to verify the executable file 135. In this way, both the signing operation of the certificate management device 120 on the original executable file 207 and the verification operation of the electronic device 110 on the executable file 135 can be simplified.

[0063] As mentioned above, in some other embodiments, the certificate management device 120 may sign the original executable file 207 using an intermediate certificate based on the vehicle digital certificate 125 as the root certificate, instead of directly using the vehicle digital certificate 125 as the root certificate. For example, the certificate management device 120 may use the private key corresponding to the intermediate certificate to sign the original executable file 207. In such a case, when verifying (220) the executable file 135 based on the vehicle digital certificate 125, the electronic device 110 may verify the executable file 135 based on a certificate trust chain with the vehicle digital certificate 125 as the root certificate. As used herein, the certificate trust chain may also be simply referred to as a "certificate chain" or "trust chain," etc.

[0064] Generally, a certificate trust chain refers to a chain structure of certificates including a root certificate and one or more intermediate certificate levels. When verifying executable file 135 based on the certificate chain, electronic device 110 can sequentially use intermediate certificates (e.g., public keys) at different levels to perform verification layer by layer until the vehicle digital certificate 125, which serves as the root certificate, is reached. By using the certificate trust chain, certificate management device 120 does not need to directly sign the original executable file 207 using the vehicle digital certificate 125 as the root certificate. Instead, it can use intermediate certificates based on the root certificate to sign the original executable file 207, thereby avoiding the exposure risks or other risks that may invalidate the root certificate due to direct use of the root certificate, thus improving the information security of the root certificate.

[0065] It should be noted that the electronic device 110 can obtain the vehicle digital certificate 125 for verifying the executable file 135 through any suitable means. For example, in some embodiments, the vehicle digital certificate 125 can be pre-set in the electronic device 110 when it is manufactured. In this way, the electronic device 110 does not need to obtain the vehicle digital certificate 125 separately in subsequent operations, thereby simplifying the operation of the electronic device 110. In other embodiments, the electronic device 110 can obtain the vehicle digital certificate 125 generated by the certificate management device 120 based on the information of the vehicle 105 from any suitable third-party device. In this way, the availability of the vehicle digital certificate 125 to the electronic device 110 can be improved because it can be obtained from a variety of third parties.

[0066] In other embodiments, electronic device 110 may receive vehicle digital certificate 125 from certificate management device 120. That is, after generating vehicle digital certificate 125 based on information related to vehicle 105, certificate management device 120 may send vehicle digital certificate 125 (e.g., public key) to electronic device 110. In this way, electronic device 110 can obtain vehicle digital certificate 125 directly and conveniently from certificate management device 120, thereby avoiding obtaining vehicle digital certificate 125 from other intermediate devices, improving the information security of electronic device 110 obtaining vehicle digital certificate 125, and simplifying the operation of electronic device 110 in obtaining vehicle digital certificate 125.

[0067] In some embodiments, if the electronic device 110 determines that it has received a vehicle digital certificate 125 from the certificate management device 120, the electronic device 110 may store the vehicle digital certificate 125 in a secure storage area 115 of the electronic device 110. In this way, since the secure storage area 115 is a storage area with a higher security level and higher storage security, the information security of the vehicle digital certificate 125 at the electronic device 110 is improved. Of course, in other embodiments, the electronic device 110 may also store the vehicle digital certificate 125 in a general storage area or other types of storage areas, thereby improving the convenience of storing and accessing the vehicle digital certificate 125.

[0068] When electronic device 110 stores vehicle digital certificate 125 in secure storage area 115, if electronic device 110 determines that it has received (218) executable file 135 from executable file management device 130, electronic device 110 can retrieve vehicle digital certificate 125 from secure storage area 115 for use in verifying executable file 135. In this way, since electronic device 110 obtains vehicle digital certificate 125 from local secure storage area 115 without having to temporarily request vehicle digital certificate 125 from certificate management device 120, the verification process of executable file 135 is accelerated, and verification efficiency is improved. On the other hand, since vehicle digital certificate 125 is stored in secure storage area 115, the information security of vehicle digital certificate 125 is also improved.

[0069] By verifying (220) the executable file 135, if the electronic device 110 determines that the executable file 135 is safe, then the electronic device 110 can execute (222) the executable file 135. For example, the electronic device 110 can run the verified application installer to install the corresponding application on the electronic device 110 to provide the corresponding application service or function to the occupants of the vehicle 105. On the other hand, if the electronic device 110 determines that the executable file 135 is unsafe, the electronic device 110 can abandon the execution of the executable file 135 and instead delete the executable file 135, or it can use any other safe method to handle the executable file 135.

[0070] Through the example interaction process 200, the certificate management device 120 can sign the executable file 135 based on the vehicle digital certificate (e.g., vehicle digital certificate 125) of the vehicle (e.g., vehicle 105). This verifies the legitimacy of the vehicle digital certificate 125 for the executable file 135, thereby preventing executable files from being run on the electronic device 110 of vehicle 105 by unknown developers. For example, in some embodiments, since each vehicle (e.g., vehicle 105) can have a unique and exclusive vehicle digital certificate, the executable file 135 can only be executed on the electronic device 110 of vehicle 105 after passing verification based on the vehicle digital certificate 125 or the certificate chain (or trust chain) associated with the vehicle digital certificate 125. If the executable file 135 fails such verification, it can be considered an invalid executable file, thereby preventing unknown executable files from being installed on the electronic device 110 of vehicle 105, thus enhancing the security of the executable file through the vehicle digital certificate 125.

[0071] Figure 3 An example interaction process 300 is illustrated between an electronic device 110 in a vehicle 105, a secure storage area 115 of the electronic device 110, a certificate management device 120, an executable file management device 130, and an application developer device 140, according to an embodiment of the present disclosure. For purposes of discussion, reference will be made below. Figure 1 This describes the example interaction process 300. However, it should be understood that the example interaction process 300 can also be applied to any other scenario where the security of executable files is ensured based on vehicle digital certificates so that they can run on in-vehicle electronic devices. It should be noted that the example interaction process 300 can be considered as a reference to the above. Figure 2 This describes one example implementation of the example interaction process 200. It should also be noted that in the example interaction process 300, the interaction between the electronic device 110 and the secure storage area 115 can be understood as a process within the operating system of the electronic device 110, such as the interaction between different processes.

[0072] like Figure 3As shown, certificate management device 120 can use information from vehicle 105 to generate (302) a vehicle digital certificate 125 for vehicle 105. In some embodiments, the information from vehicle 105 used to generate the vehicle digital certificate 125 may be a unique identifier for vehicle 105. For example, the unique identifier for vehicle 105 may be the vehicle identification number (VIN) or vehicle identifier (VID) of vehicle 105. Then, certificate management device 120 may send the vehicle digital certificate 125 (e.g., a public key) to electronic device 110 (304). In some embodiments, certificate management device 120 may also provide electronic device 110 with a certificate trust chain using vehicle digital certificate 125 as the root certificate. For example, the certificate trust chain may include a root certificate and one or more levels of intermediate certificates. After receiving (306) vehicle digital certificate 125 from certificate management device 120, electronic device 110 may write vehicle digital certificate 125 to (308) secure storage area 115, and secure storage area 115 may store (310) vehicle digital certificate 125.

[0073] On the other hand, the application developer device 140 can send (312) a developer digital certificate application 313 to the certificate management device 120 to apply for a developer certificate used to prove the identity of the application developer, that is, a certificate used for the purpose of developing the application. In some embodiments, the owner's public key and the certificate issuer of the developer certificate can be the certificate authority corresponding to the certificate management device 120. After receiving (314) the developer digital certificate application 313 from the application developer device 140, the certificate management device 120 can return (316) the developer digital certificate 317 to the application developer device 140. It should be noted that the application developer device 140 may only need to apply for the developer digital certificate 317 from the certificate management device 120 when developing an application installer for the vehicle 105 for the first time. After obtaining the developer digital certificate 317 from the certificate management device 120, the application developer device 140 does not need to apply for the developer digital certificate 317 from the certificate management device 120 again before developing the application installer, but can continue to use the developer digital certificate 317 until its validity period expires.

[0074] After receiving (318) the developer digital certificate 317 from the certificate management device 120, the application developer device 140 can sign (320) the developed application installer based on the developer digital certificate 317 (e.g., using the private key corresponding to the certificate), thereby generating the original application installer 323. The application developer device 140 can then submit the original application installer 323 to the executable file management device 130 (322). After receiving (324) the original application installer 323 from the application developer device 140, the executable file management device 130 can verify (326) the original application installer 323 based on the developer digital certificate 317 (e.g., the public key) to determine whether the original application installer 323 is signed based on the developer certificate issued by the certificate management device 120.

[0075] Next, the executable file management device 130 can return (328) a submission result 329 to the application developer device 140, and the application developer device 140 can receive (330) the submission result 329 from the executable file management device 130. For example, if the executable file management device 130 verifies the original application installer 323, the executable file management device 130 can send "submission successful" or other similar positive submission result to the application developer device 140. Conversely, if the executable file management device 130 fails to verify the original application installer 323, the executable file management device 130 can send "submission unsuccessful" or other similar negative submission result to the application developer device 140.

[0076] If the original application installer 323 is successfully submitted, the executable file management device 130 can send the original application installer 323 to the certificate management device 120 (332) to request an application installer signed based on the vehicle digital certificate 125 for a single vehicle 105. After receiving the original application installer 323 from the executable file management device 130 (334), the certificate management device 120 can sign the original application installer 323 based on the vehicle digital certificate 125 (336). Then, the certificate management device 120 can return the signed application installer 339 to the executable file management device 130 (338).

[0077] At the electronic device 110 of vehicle 105, in order to verify the signed application installer 339, electronic device 110 can provide (342) a message 343 to secure storage area 115 for obtaining vehicle digital certificate 125 and certificate chain 347. After receiving (344) message 343, secure storage area 115 can return (346) vehicle digital certificate 125 and certificate chain 347 to electronic device 110, so electronic device 110 can obtain (348) vehicle digital certificate 125 and certificate chain 347 from secure storage area 115. It should be noted that, although in Figure 3 In this illustration, the process of electronic device 110 obtaining vehicle digital certificate 125 and certificate chain 347 from secure storage area 115 is shown before electronic device 110 obtains the signed application installer 339 from executable file management device 130; however, this is merely illustrative and is not intended to limit the scope of this disclosure in any way. In other embodiments, electronic device 110 may obtain vehicle digital certificate 125 and certificate chain 347 from secure storage area 115 after obtaining the signed application installer 339 from executable file management device 130.

[0078] At executable file management device 130, after receiving (340) the signed application installer 339 from certificate management device 120, executable file management device 130 may send the signed application installer 339 to electronic device 110 (350). After receiving (352) the signed application installer 339 from executable file management device 130, electronic device 110 may verify (354) the signed application installer 339 based on vehicle digital certificate 125 and / or certificate chain 347. If, after verification, electronic device 110 confirms that the signed application installer 339 is secure, then electronic device 110 may install (356) the signed application installer 339. Conversely, if, after verification, electronic device 110 confirms that the signed application installer 339 is insecure, then electronic device 110 may avoid installing the signed application installer 339. Then, the electronic device 110 can return (358) the application installation result 359 to the executable file management device 130, and the executable file management device 130 can receive (360) the application installation result 359 from the electronic device 110. For example, the application installation result 359 can indicate to the executable file management device 130 whether the application installation program 339 was installed successfully.

[0079] Through example interaction process 300, embodiments of this disclosure provide a signing mechanism for executable files based on vehicle digital certificates using vehicle-specific information (e.g., unique identifiers), thereby providing a management mechanism for executable files used in vehicle electronic devices. Embodiments of this disclosure use a self-issued vehicle digital certificate as the root certificate to sign the executable file, thus adding a security management mechanism based on the vehicle digital certificate to the existing executable file packaging and signing mechanism. Furthermore, in some embodiments, during the verification process of executable files in vehicle electronic devices, the signed executable file can be verified based on a trust chain of the vehicle digital certificate. After the trust chain of the vehicle digital certificate is confirmed, the vehicle electronic device can then use the vehicle digital certificate to verify the integrity and completeness of the executable file, thereby strengthening the security of the executable file for the vehicle electronic device.

[0080] In some embodiments, unlike the signing of the original executable file by the certificate management device in example interaction process 300, the certificate management device can generate an intermediate certificate using the vehicle's own security foundation certificate (i.e., the vehicle digital certificate), and then provide the intermediate certificate to the application developer, or issue an intermediate certificate to the application developer. The application developer can use the issued intermediate certificate to sign the developed executable file. Before running the executable file, the vehicle electronic device can first verify the signature certificate of the executable file using a trust chain based on the vehicle digital certificate, thereby ensuring the legitimacy of the signature certificate of the executable file. Furthermore, it should be noted that the embodiments of this disclosure provide a general private signature mechanism for executable files, the application scenarios of which are not limited to in-vehicle electronic devices, but can be equally applied to the digital signature of all executable files (e.g., binary program files). Such executable files may include, but are not limited to, executable files for Linux systems, executable files for Android systems, and executable files for iOS systems, etc.

[0081] Figure 4 A flowchart illustrating an example process 400 of an information processing method performed at an electronic device in a vehicle according to an embodiment of the present disclosure is provided. In some embodiments, the example process 400 may be implemented by an electronic device 110 of the vehicle 105 in the example environment 100, for example, by a processor or processing unit of the electronic device 110. In other embodiments, the example process 400 may also be implemented by other devices independent of the example environment 100, or by other devices within the example environment 100. For ease of explanation, reference will be made below. Figure 1 Let's discuss example process 400.

[0082] At box 410, the electronic device 110 of vehicle 105 receives an executable file 135 from the executable file management device 130, the executable file 135 being signed based on the vehicle digital certificate 125 of vehicle 105. At box 420, the executable file 135 is verified based on the vehicle digital certificate 125 to determine the security of the executable file 135. At box 430, the electronic device 110 determines whether the executable file 135 is secure. At box 440, if the electronic device 110 determines that the executable file 135 is secure, the electronic device 110 executes the executable file 135 on the electronic device 110.

[0083] In some embodiments, electronic device 110 receives vehicle digital certificate 125 from certificate management device 120, which is generated by certificate management device 120 based on a unique identifier of vehicle 105. In some embodiments, if it is determined that vehicle digital certificate 125 has been received from certificate management device 120, electronic device 110 stores vehicle digital certificate 125 in secure storage area 115 of electronic device 110. In some embodiments, when verifying executable file 135 based on vehicle digital certificate 125, electronic device 110 verifies executable file 135 based on a certificate trust chain with vehicle digital certificate 125 as the root certificate. In some embodiments, if it is determined that executable file 135 has been received from executable file 135 management device 130, electronic device 110 retrieves vehicle digital certificate 125 from secure storage area 115 of electronic device 110. In some embodiments, the unique identifier includes the vehicle identification number (VIN) of vehicle 105. In some embodiments, executable file 135 includes an application installation file.

[0084] Figure 5 A flowchart illustrating an example process 500 of an information processing method executed at a certificate management device according to an embodiment of the present disclosure is provided. In some embodiments, the example process 500 may be implemented by a certificate management device 120 in the example environment 100, for example, by a processor or processing unit of the certificate management device 120. In other embodiments, the example process 500 may also be implemented by other devices independent of the example environment 100, or by other devices within the example environment 100. For ease of explanation, reference will be made below. Figure 1 Let's discuss example process 500.

[0085] At box 510, certificate management device 120 generates a vehicle digital certificate 125 for vehicle 105 based on information about vehicle 105. At box 520, certificate management device 120 receives a raw executable file from executable file management device 130, which will be executed on electronic device 110 of vehicle 105. At box 530, certificate management device 120 signs the raw executable file based on vehicle digital certificate 125 to generate an executable file 135 for transmission to electronic device 110. At box 540, certificate management device 120 sends executable file 135 to executable file management device 130.

[0086] In some embodiments, certificate management device 120 sends vehicle digital certificate 125 to electronic device 110. In some embodiments, when signing the original executable file based on vehicle digital certificate 125, certificate management device 120 generates an intermediate certificate based on vehicle digital certificate 125, and certificate management device 120 uses the intermediate certificate to sign the original executable file. In some embodiments, if it is determined that a request for a developer digital certificate has been received from the application developer's device, certificate management device 120 generates a developer digital certificate based on the application developer's information, and certificate management device 120 sends the developer digital certificate to the application developer's device. In some embodiments, the information of vehicle 105 used to generate vehicle digital certificate 125 includes a unique identifier for vehicle 105. In some embodiments, the unique identifier includes the vehicle identification number (VIN) of vehicle 105. In some embodiments, executable file 135 includes application installation files.

[0087] Figure 6 A flowchart illustrating an example process 600 of an information processing method executed at an executable file management device according to an embodiment of the present disclosure is provided. In some embodiments, the example process 600 may be implemented by the executable file management device 130 in the example environment 100, for example, by a processor or processing unit of the executable file management device 130. In other embodiments, the example process 600 may also be implemented by other devices independent of the example environment 100, or by other devices within the example environment 100. For ease of explanation, reference will be made below. Figure 1 Let's discuss example process 600.

[0088] At box 610, executable file management device 130 determines whether the original executable file will be provided to electronic device 110 of vehicle 105. At box 620, if it is determined that the original executable file will be provided to electronic device 110 of vehicle 105, executable file management device 130 sends the original executable file to certificate management device 120. At box 640, executable file 135 for sending to electronic device 110 is received from certificate management device 120, executable file 135 being signed based on vehicle digital certificate 125 of vehicle 105. At box 644, executable file 135 is sent to electronic device 110.

[0089] In some embodiments, if a request for an original executable file is received from electronic device 110, executable file management device 130 determines that the original executable file will be provided to electronic device 110. In some embodiments, executable file management device 130 receives the original executable file from an application developer's device, the original executable file being signed using the application developer's developer digital certificate. Executable file management device 130 then verifies the original executable file based on the developer digital certificate. In some embodiments, vehicle digital certificate 125 is generated based on a unique identifier for vehicle 105. In some embodiments, the unique identifier includes the vehicle identification number (VIN) of vehicle 105. In some embodiments, executable file 135 includes an application installation file.

[0090] Figure 7 A block diagram of an example device 700 that can be used to implement embodiments of the present disclosure is shown. In some embodiments, the example device 700 may be an electronic device that can be used to implement... Figure 1 The computing device 125 in the middle. For example... Figure 7 As shown, the example device 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to computer program instructions stored in a read-only storage device (ROM) 702 or loaded from a storage unit 708 into a random access storage device (RAM) 703. The RAM 703 may also store various programs and data required for the operation of the example device 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0091] Multiple components in the example device 700 are connected to the I / O interface 705, including: an input unit 706, such as a keyboard, mouse, etc.; an output unit 707, such as various types of displays, speakers, etc.; a storage unit 708, such as a disk, optical disk, etc.; and a communication unit 709, such as a network interface card, modem, wireless transceiver, etc. The communication unit 709 allows the example device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0092] The various processes and procedures described above, such as example methods or example procedures, may be executed by processing unit 701. For example, in some embodiments, the various example methods or example procedures may be implemented as computer software programs tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on example device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by CPU 701, one or more steps of the example methods or example procedures described above may be performed. Alternatively, in other embodiments, CPU 701 may be configured to execute the example methods described herein by any other suitable means (e.g., by means of firmware).

[0093] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0094] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0095] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0096] As used herein, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. This document may also include other explicit and implicit definitions. As used herein, the term "determine" covers a wide variety of actions. For example, "determine" can include calculation, computation, processing, derivation, investigation, search (e.g., searching in a table, database, or other data structure), ascertainment, etc. Furthermore, "determine" can include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), etc. In addition, "determine" can include parsing, selecting, choosing, building, etc.

[0097] It should be noted that the embodiments of this disclosure can be implemented using hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, code provided on programmable memory or a data carrier such as an optical or electronic signal carrier.

[0098] Furthermore, although the operation of the methods of this disclosure is described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Rather, the steps depicted in the flowcharts may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps. It should also be noted that the features and functions of two or more devices according to this disclosure may be embodied in one device. Conversely, the features and functions of one device described above may be further divided and embodied by multiple devices. While this disclosure has been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. An information processing method, comprising: At the vehicle's electronic devices, an executable file is received from an executable file management device. The executable file is generated by the executable file management device verifying the original executable file based on the developer's digital certificate, and after successful verification, it is signed by the certificate management device based on the private key corresponding to the vehicle's digital certificate. The executable file is then pre-stored in the executable file management device. The vehicle digital certificate is generated based on the vehicle's information. The executable file is verified based on the vehicle digital certificate to determine its security. as well as If it is determined that the executable file is safe, the executable file is executed on the electronic device.

2. The method according to claim 1, further comprising: The vehicle digital certificate is received from the certificate management device, and the vehicle digital certificate is generated by the certificate management device based on the vehicle's unique identifier.

3. The method according to claim 2, further comprising: If it is determined that the vehicle digital certificate has been received from the certificate management device, the vehicle digital certificate is stored in the secure storage area of ​​the electronic device.

4. The method according to claim 1, wherein verifying the executable file based on the vehicle digital certificate includes: The executable file is verified based on a certificate trust chain with the vehicle digital certificate as the root certificate.

5. The method according to claim 1, further comprising: If it is determined that the executable file has been received from the executable file management device, the vehicle digital certificate is retrieved from the secure storage area of ​​the electronic device.

6. An information processing method, comprising: At the certificate management device, a vehicle digital certificate is generated specifically for the vehicle based on the vehicle's information; Receives an original executable file, which will be executed on the electronic devices of the vehicle, from the executable file management device, the original executable file being verified by the executable file management device based on the developer's digital certificate; The original executable file is signed based on the private key corresponding to the vehicle's digital certificate to generate an executable file for sending to the electronic device; as well as The executable file is sent to the executable file management device so that the executable file is pre-stored in the executable file management device for use in response to a request from the electronic device.

7. The method according to claim 6, further comprising: Send the vehicle digital certificate to the electronic device.

8. The method of claim 6, wherein signing the original executable file based on the private key corresponding to the vehicle digital certificate comprises: An intermediate certificate is generated based on the vehicle digital certificate; as well as The original executable file is signed using the private key corresponding to the intermediate certificate.

9. The method according to claim 6, further comprising: If it is determined that a request for the developer's digital certificate has been received from the application developer's device, the developer's digital certificate is generated based on the application developer's information; as well as Send the developer's digital certificate to the application developer's device.

10. The method of claim 6, wherein the information of the vehicle includes a unique identifier of the vehicle.

11. An information processing method, comprising: At the executable file management device, the original executable file is verified using the application developer's developer digital certificate. After successful verification, if it is determined that the original executable file will be provided to the vehicle's electronic devices, the original executable file is sent to the certificate management device. The certificate management device receives an executable file for sending to the electronic device, the executable file being signed by the certificate management device based on a private key corresponding to a vehicle digital certificate specifically for the vehicle, the vehicle digital certificate being generated based on information about the vehicle; The executable file is stored in the executable file management device; as well as In response to receiving a request for the executable file from the electronic device, the executable file is sent to the electronic device.

12. The method of claim 11, further comprising: If it is determined that a request for the original executable file has been received from the electronic device, it is determined that the original executable file will be provided to the electronic device.

13. The method of claim 11, further comprising: The original executable file is received from the application developer's device and is signed using the application developer's developer digital certificate; as well as The original executable file is verified based on the developer's digital certificate.

14. The method of claim 11, wherein the vehicle digital certificate is generated based on the vehicle's unique identifier.

15. An information processing device, comprising: At least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the device to perform actions when executed by the at least one processing unit, the actions including: At the vehicle's electronic devices, an executable file is received from an executable file management device. The executable file is generated by the executable file management device verifying the original executable file based on the developer's digital certificate, and after successful verification, it is signed by the certificate management device based on the private key corresponding to the vehicle's digital certificate. The executable file is then pre-stored in the executable file management device. The vehicle digital certificate is generated based on the vehicle's information. The executable file is verified based on the vehicle digital certificate to determine its security; and If it is determined that the executable file is safe, the executable file is executed on the electronic device.

16. An information processing device, comprising: At least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the device to perform actions when executed by the at least one processing unit, the actions including: At the certificate management device, a vehicle digital certificate is generated specifically for the vehicle based on the vehicle's information; Receives an original executable file, which will be executed on the electronic devices of the vehicle, from the executable file management device, the original executable file being verified by the executable file management device based on the developer's digital certificate; The original executable file is signed using the private key corresponding to the vehicle's digital certificate to generate an executable file for sending to the electronic device; and The executable file is sent to the executable file management device so that the executable file is pre-stored in the executable file management device for use in response to a request from the electronic device.

17. An information processing device, comprising: At least one processing unit; as well as At least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the device to perform actions when executed by the at least one processing unit, the actions including: At the executable file management device, the original executable file is verified using the application developer's developer digital certificate. After successful verification, if it is determined that the original executable file will be provided to the vehicle's electronic devices, the original executable file is sent to the certificate management device. The certificate management device receives an executable file for sending to the electronic device, the executable file being signed by the certificate management device based on a private key corresponding to a vehicle digital certificate specifically for the vehicle, the vehicle digital certificate being generated based on information about the vehicle; The executable file is stored in the executable file management device; and In response to receiving a request for the executable file from the electronic device, the executable file is sent to the electronic device.

18. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of claims 1 to 5.

19. A computer-readable storage medium having a computer program stored thereon, the program, when executed by a processor, implementing the method according to any one of claims 6 to 10.

20. A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method according to any one of claims 11 to 14.

Images