Authority management method, electronic equipment, storage medium and chip system

Abstract

The embodiment of the invention provides an authority management method, electronic equipment, a storage medium and a chip system, and relates to the technical field of terminals. The method comprises the steps that an authorization center root certificate can be preset in a system of the electronic equipment, and a credible trust chain is established. The application may apply intra-system authority credentials from the electronic device system based on credentials applied to the authorization center. In this way, the service in the electronic device system may authenticate and access control the application based on the intra-system authority credentials. Therefore, a safe and controllable authority management system can be constructed in the electronic equipment system, and identity authentication and refined authority management of the application are realized.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a permission management method, electronic device, storage medium and chip system. Background Technology

[0002] In some implementations, electronic devices can identify and control applications' interface access based on application signatures. If the application signature verification passes, the application can access system resources within the electronic device.

[0003] However, this access control method lacks fine-grained control over application identity and application access permissions. Summary of the Invention

[0004] This application provides a permission management method, an electronic device, a storage medium, and a chip system. Services in the electronic device system can authenticate and control applications based on system-internal permission certificates, enabling the construction of a secure and controllable permission management system in the electronic device system and realizing application identity authentication and fine-grained permission management.

[0005] The first aspect provides a permission management method, which includes:

[0006] If the first module of the electronic device verifies the first application of the electronic device, the first module sends the first certificate to the first application; the first service of the electronic device obtains the first information of the first application, the first information being used to request business interaction with the first service, the first information including the first certificate; the first service verifies the first certificate; if the first certificate verification is successful, the first service interacts with the first application.

[0007] The first service can authenticate and control access to the first application based on the permission certificate within the electronic device system (corresponding to the first certificate). This enables the construction of a secure and controllable permission management system in the vehicle system, achieving application identity authentication and fine-grained permission management.

[0008] In one possible implementation, before the first module sends the first certificate to the first application after the first module of the electronic device has passed the verification of the first application of the electronic device, the method further includes: the first module obtaining second information of the first application, the second information including the first signature information of the authorization center; the first module verifying the first signature information; and the first module sending the first certificate to the first application after the first module of the electronic device has passed the verification of the first application of the electronic device, including: the first module sending the first certificate to the first application after the first signature information has passed the verification.

[0009] Taking an in-vehicle infotainment system as an example, the system establishes a trusted chain of trust between the external authorization center and the in-vehicle permission management center by pre-installing the root certificate of the authorization center. The first application, based on the certificate obtained from the external authorization center, applies to the in-vehicle infotainment system for an in-vehicle permission certificate. In this way, the first service in the in-vehicle infotainment system can authenticate and control the first application based on the in-vehicle permission certificate, thereby enabling the construction of a secure and controllable permission management system within the in-vehicle infotainment system, achieving application identity authentication and fine-grained permission management.

[0010] In one possible implementation, the first signature information is obtained by signing the identity credentials and permission scope of the first application based on the first private key of the authorization center.

[0011] The initial permission certificate ensures the legitimacy of the application. The in-vehicle permission management center can verify the signature of the external authorization center to confirm that the application's initial permission certificate was issued by the external authorization center, thereby establishing a trusted application identity and determining the scope of the application's permissions.

[0012] In one possible implementation, the identity credentials of the first application include a second public key, which is generated by an authorization center or by the first application; and / or, the identity credentials of the first application include a first value, which is a hash value obtained by hashing the application package of the first application.

[0013] The identity credentials of the first application can have different representation methods. The vehicle system can flexibly choose different representation methods according to specific circumstances such as security requirements, scenario convenience, or device capabilities, thus expanding the feasibility of the access control solution.

[0014] In one possible implementation, the first module has a pre-configured first public key of the authorization center corresponding to the first private key; the first module verifies the first signature information, including: the first module verifies the first signature information based on the first public key; if the first signature information is verified successfully, the first module sends the first certificate to the first application, including: if the first module successfully decrypts the first signature information based on the first public key, the first module sends the first certificate to the first application.

[0015] The first module establishes a trusted chain of trust between the external authorization center and the in-vehicle permission management center by pre-installing the root certificate (including the first public key) of the authorization center. Based on the first public key, the first module can verify the trustworthiness of the first application, thereby building a secure and controllable permission management system to achieve application authentication and fine-grained permission management.

[0016] In one possible implementation, the second information is a digital certificate generated by the first application that contains the first signature information; or, the second information is a signature obtained by signing the first signature information based on the private key of the first application.

[0017] The in-vehicle access control center is responsible for managing the certificate lifecycle of in-vehicle services and applications (including certificate issuance, renewal, and revocation). The second message sent by the first application to the in-vehicle access control center enables the center to authenticate and control the first application, thereby improving the security of application access to system data and preventing unauthorized access or tampering with system data.

[0018] In one possible implementation, the first certificate carries the second signature information of the first module. If the identity credential of the first application includes the second public key, the second signature information is the signature information obtained by signing the second public key and the scope of permissions based on the third private key of the first module; or, the second signature information is the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key; wherein the fourth public key is generated by the first application or generated by the first module for the first application.

[0019] When the identity credentials of the first application include a second public key, the second signature information can include various implementations. Specifically, the second signature information can be a signature using the private key (i.e., the third private key) of the in-vehicle access control center to sign the original public key (i.e., the second public key) and the permissions; or it can be a signature using the private key of the in-vehicle access control center to sign a fourth public key and the permissions. The fourth public key can be generated by the in-vehicle access control center or the application. It is understandable that using the private key of the in-vehicle access control center for signing allows services and applications to interact based on the same trust anchor. In this way, a secure and controllable access control system can be built in the vehicle system, enabling application authentication and fine-grained access control.

[0020] In one possible implementation, the first certificate carries the second signature information of the first module. When the identity credential of the first application includes the first value, the second signature information is the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key of the first module; wherein the fourth public key is generated by the first application or generated by the first module for the first application.

[0021] Given that the identity credentials of the first application include the first value, the second signature information can be a signature obtained by signing the fourth public key and the permissions using the private key of the in-vehicle access control center (i.e., the third private key). The fourth public key can be generated by the in-vehicle access control center or the application. It is understandable that using the private key of the in-vehicle access control center for signing allows services and applications to interact based on the same trust anchor. In this way, a secure and controllable access control system can be built in the vehicle system, enabling application authentication and fine-grained access control.

[0022] In one possible implementation, the first service has a pre-configured third public key of the first module corresponding to the third private key; the first service verifies the first certificate, including: the first service verifies the second signature information in the first certificate based on the third public key; if the first certificate verification is successful, the first service interacts with the first application, including: if the second signature information is successfully decrypted based on the third public key, the first service interacts with the first application.

[0023] The first service can verify the first application's first certificate (i.e., the in-vehicle permission certificate) based on the root certificate (containing a third public key) of the in-vehicle permission management center. The first service and the first application can interact using the same working key. Since other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus improving data transmission security. Furthermore, the in-vehicle service enables centralized and standardized access control of system resources, allowing for fine-grained management of application authentication and permissions, thereby enhancing the security of the vehicle's infotainment system.

[0024] In one possible implementation, the first module includes a third public key corresponding to a third private key; the first service verifies the first certificate, including: the first service sends the first certificate to the first module; based on the third public key, the first module verifies the second signature information in the first certificate; if the first certificate verification is successful, the first service interacts with the first application, including: if the second signature information is successfully decrypted based on the third public key, the first service interacts with the first application.

[0025] The first service can send the first application's first certificate to the in-vehicle access control center, which will then verify the certificate. If the verification passes, the first service can interact with the first application, such as granting it access to system resources. The first service and the first application can interact based on the same working key. Since other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus improving data transmission security. Furthermore, the in-vehicle service enables centralized and standardized access control of system resources, allowing for fine-grained management of application authentication and permissions, thereby enhancing the security of the vehicle's infotainment system.

[0026] In one possible implementation, before the first service interacts with the first application, the process further includes: the first service generating a first working key based on its fifth private key and the first application's public key, wherein the first application's public key is either the fourth public key or the second public key; the first application generating a second working key based on its private key and the first service's fifth public key, wherein the first application's private key is either the private key corresponding to the fourth public key or the private key corresponding to the second public key, and the fifth public key is the public key corresponding to the fifth private key; the first service interacting with the first application includes: the first service interacting with the first application based on the first working key, and the first application interacting with the first service based on the second working key.

[0027] The primary service and the primary application interact using the same working key, which enhances the confidentiality and integrity of data during cross-process transmission. This ensures that even if data is intercepted by other applications or services, they cannot decrypt it, thus improving the security of the vehicle's infotainment system.

[0028] The second aspect provides another permission management method for electronic devices, which includes:

[0029] If the verification of the first application of the electronic device passes, a first certificate is sent to the first application; first information of the first service of the first application for the electronic device is obtained, the first information is used to request business interaction with the first service, and the first information includes the first certificate; the first certificate is verified; if the verification of the first certificate passes, business interaction is performed with the first application based on the first service.

[0030] Based on the access certificate within the electronic device system (corresponding to the first certificate), the electronic device can authenticate and control access to the first application. This allows for the construction of a secure and controllable access management system within the vehicle's infotainment system, enabling application authentication and fine-grained access control.

[0031] In one possible implementation, before sending the first certificate to the first application after the verification of the first application of the electronic device passes, the method further includes: obtaining second information of the first application for the first module, the second information including the first signature information of the authorization center; verifying the first signature information; and sending the first certificate to the first application after the verification of the first application of the electronic device passes, including: sending the first certificate to the first application after the verification of the first signature information passes.

[0032] By using a pre-installed root certificate from the authorization center, a trusted chain of trust can be established between the external authorization center and the in-vehicle permission management center in the vehicle infotainment system. The first application, based on the certificate obtained from the external authorization center, applies to the vehicle infotainment system for an in-vehicle permission certificate. In this way, the first service in the vehicle infotainment system can authenticate and control the first application based on the in-vehicle permission certificate, thereby enabling the construction of a secure and controllable permission management system within the vehicle infotainment system, achieving application authentication and fine-grained permission management.

[0033] In one possible implementation, the first signature information is obtained by signing the identity credentials and permission scope of the first application based on the first private key of the authorization center.

[0034] The initial permission certificate ensures the legitimacy of the application. The in-vehicle permission management center can verify the signature of the external authorization center to confirm that the application's initial permission certificate was issued by the external authorization center, thereby establishing a trusted application identity and determining the scope of the application's permissions.

[0035] In one possible implementation, the identity credentials of the first application include a second public key, which is generated by an authorization center or by the first application; and / or, the identity credentials of the first application include a first value, which is a hash value obtained by hashing the application package of the first application.

[0036] The identity credentials of the first application can have different representation methods. The vehicle system can flexibly choose different representation methods according to specific circumstances such as security requirements, scenario convenience, or device capabilities, thus expanding the feasibility of the access control solution.

[0037] In one possible implementation, the first module pre-configures a first public key of an authorization center corresponding to the first private key; verifies the first signature information, including: verifying the first signature information based on the first public key; and sends a first certificate to the first application if the first signature information is verified successfully, including: sending the first certificate to the first application if the first signature information is successfully decrypted based on the first public key.

[0038] By pre-installing the root certificate (including the first public key) of the authorization center, a trusted chain of trust can be established between the external authorization center and the in-vehicle permission management center. Based on the first public key, the trustworthiness of the first application can be verified, thereby building a secure and controllable permission management system to achieve application authentication and fine-grained permission management.

[0039] In one possible implementation, the second information is a digital certificate generated by the first application that contains the first signature information; or, the second information is a signature obtained by signing the first signature information based on the private key of the first application.

[0040] The in-vehicle access control center can manage the certificate lifecycle of in-vehicle services and applications (including certificate issuance, renewal, revocation, etc.). Electronic devices obtain secondary information from the in-vehicle access control center for the first application, enabling authentication and access control of the first application, thereby improving the security of application access to system data and preventing unauthorized access or tampering with system data.

[0041] In one possible implementation, the first certificate carries the second signature information of the first module. If the identity credential of the first application includes the second public key, the second signature information is the signature information obtained by signing the second public key and the scope of permissions based on the third private key of the first module; or, the second signature information is the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key; wherein the fourth public key is generated by the first application or generated by the first module for the first application.

[0042] When the identity credentials of the first application include a second public key, the second signature information can include various implementations. Specifically, the second signature information can be a signature using the private key (i.e., the third private key) of the in-vehicle access control center to sign the original public key (i.e., the second public key) and the permissions; alternatively, it can be a signature using the private key of the in-vehicle access control center to sign a fourth public key and the permissions. Using the private key of the in-vehicle access control center for signing allows services and applications to interact based on the same trust anchor. In this way, a secure and controllable access control system can be built in the vehicle system, enabling application authentication and fine-grained access control.

[0043] In one possible implementation, the first certificate carries the second signature information of the first module. When the identity credential of the first application includes the first value, the second signature information is the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key of the first module; wherein the fourth public key is generated by the first application or generated by the first module for the first application.

[0044] Given that the identity credentials of the first application include the first value, the second signature information can be a signature obtained by signing the fourth public key and the permission using the private key of the in-vehicle access control center (i.e., the third private key). Using the private key of the in-vehicle access control center for signing allows services and applications to interact based on the same trust anchor. In this way, a secure and controllable access control system can be built in the vehicle system, enabling application authentication and fine-grained access control.

[0045] In one possible implementation, the first service is pre-configured with a third public key of the first module corresponding to the third private key; the first certificate is verified, including: verifying the second signature information in the first certificate based on the third public key; if the first certificate is verified successfully, business interaction is performed between the first service and the first application, including: if the second signature information is successfully decrypted, business interaction is performed between the first service and the first application.

[0046] Electronic devices can verify the first certificate (i.e., the in-vehicle access certificate) of the first application based on the root certificate (containing a third public key) of the in-vehicle access management center. The first service and the first application can interact using the same working key. Since other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus improving data transmission security. Furthermore, electronic devices achieve centralized and standardized access control of system resources through in-vehicle services. In-vehicle services can provide fine-grained management of application authentication and permissions, thereby enhancing the security of the vehicle system.

[0047] In one possible implementation, the first module includes a third public key corresponding to a third private key; verifying the first certificate includes: receiving the first certificate of the first service for the first module; verifying the second signature information in the first certificate based on the third public key; and, if the first certificate verification is successful, performing business interaction with the first application based on the first service, including: if the second signature information is successfully decrypted based on the third public key, performing business interaction with the first application based on the first service.

[0048] The electronic device can receive the first certificate from the in-vehicle access control center from the first service and verify the first certificate of the first application. If the verification of the first application is successful, the first service can interact with the first application, such as granting the first application access to system resources corresponding to its permissions. The first service and the first application can interact based on the same working key. Since other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus improving the security of data transmission. Furthermore, the electronic device achieves centralized and standardized access control of system resources through the in-vehicle service. The in-vehicle service can perform fine-grained management of application authentication and permissions, thereby improving the security of the vehicle system.

[0049] In one possible implementation, before business interaction between the first service and the first application, the method further includes: generating a first working key based on the fifth private key of the first service and the public key of the first application, wherein the public key of the first application is either the fourth public key or the second public key; generating a second working key based on the private key of the first application and the fifth public key of the first service, wherein the private key of the first application is either the private key corresponding to the fourth public key or the private key corresponding to the second public key, and the fifth public key is the public key corresponding to the fifth private key; and conducting business interaction between the first service and the first application includes: realizing business interaction between the first service and the first application based on the first working key and the second working key.

[0050] The primary service and the primary application interact using the same working key, which enhances the confidentiality and integrity of data during cross-process transmission. This ensures that even if data is intercepted by other applications or services, they cannot decrypt it, thus improving the security of the vehicle's infotainment system.

[0051] A third aspect provides a control device, which can be an electronic device, or a chip or chip system within the electronic device. The device may include a control unit and an acquisition unit. The control unit is used to control a first module of the electronic device to verify a first application of the electronic device, and also to control the first module to send a first certificate to the first application.

[0052] The acquisition unit is used to acquire first information of the first application. The first information is used to request business interaction with the first service. The first information includes the first certificate.

[0053] Specifically, the control unit is also used to control the first service to verify the first certificate, and to control the first service to perform business interactions with the first application when the first certificate is verified successfully.

[0054] In one possible implementation, the acquisition unit is used to acquire second information of the first application, the second information including the first signature information of the authorization center.

[0055] The control unit is used to control the first module to verify the first signature information, and also to control the first module to send the first certificate to the first application when the first signature information is verified.

[0056] In one possible implementation, the first signature information is the signature information obtained by signing the identity credentials and permission scope of the first application based on the first private key of the authorization center, and the first module has a first public key of the authorization center corresponding to the first private key.

[0057] The control unit is used to control the first module to verify the first signature information based on the first public key; and also to control the first module to send the first certificate to the first application if the first module successfully decrypts the first signature information based on the first public key.

[0058] In one possible implementation, if the identity credentials of the first application include a second public key, a control unit is used to control a third private key based on the first module to sign the second public key and the scope of permissions to obtain the second signature information of the first module.

[0059] Alternatively, the control unit is used to control the signing of the fourth public key and the scope of permissions of the first application based on the third private key to obtain the second signature information of the first module; wherein the second public key is generated by the authorization center or by the first application, the second signature information is carried in the first certificate, and the fourth public key is generated by the first application or by the first module for the first application.

[0060] In one possible implementation, when the identity credentials of the first application include a first value, the control unit is used to control the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key of the first module; wherein the second signature information is carried in the first certificate, and the fourth public key is generated by the first application or generated by the first module for the first application.

[0061] In one possible implementation, the first service is pre-configured with a third public key of the first module corresponding to the third private key.

[0062] The control unit is used to control the first service to verify the second signature information in the first certificate based on the third public key; it is also used to control the first service to perform business interactions with the first application if the second signature information is successfully decrypted based on the third public key.

[0063] In one possible implementation, the first module includes the third public key corresponding to the third private key.

[0064] The control unit is used to control the first service to send the first certificate to the first module; it is also used to control the first service to perform business interactions with the first application if the second signature information is successfully decrypted based on the third public key.

[0065] In one possible implementation, the control unit is configured to control a first service to generate a first working key based on a fifth private key of the first service and a public key of a first application, wherein the public key of the first application is either a fourth public key or a second public key. The control unit is also configured to control the first application to generate a second working key based on its own private key and the fifth public key of the first service, wherein the private key of the first application is either the private key corresponding to the fourth public key or the private key corresponding to the second public key, and the fifth public key is the public key corresponding to the fifth private key. The control unit is further configured to control the first service to perform business interactions with the first application based on the first working key, and to control the first application to perform business interactions with the first service based on the second working key.

[0066] When the device is an electronic device, the processing unit may be a processor. The device may also include a storage unit, which may be a memory. The storage unit is used to store programs or instructions, and the processing unit executes the programs or instructions stored in the storage unit to cause the electronic device to implement the first aspect or any possible implementation of the first aspect, or to implement the methods described in the second aspect or any possible implementation of the second aspect.

[0067] When the device is a chip or chip system within an electronic device, the processing unit can be a processor. The processing unit executes programs or instructions stored in the storage unit to cause the electronic device to implement the first aspect or any possible implementation of the first aspect, or to implement the methods described in the second aspect or any possible implementation of the second aspect. The storage unit can be a storage unit within the chip (e.g., a register, cache, etc.) or a storage unit located outside the chip within the electronic device (e.g., a read-only memory, random access memory, etc.).

[0068] The fourth aspect provides a control device including at least one processor and a memory coupled to the at least one processor. The memory is used to store programs or instructions, and the at least one processor is used to invoke the programs or instructions to perform the first aspect or any possible implementation thereof, or to perform the methods described in the second aspect or any possible implementation thereof.

[0069] The fifth aspect provides a vehicle including a control device for performing the first aspect or any possible implementation thereof, or for performing the methods described in the second aspect or any possible implementation thereof.

[0070] A sixth aspect provides a chip or chip system including at least one processor and a communication interface, the communication interface and the at least one processor being interconnected via a circuit, the at least one processor being configured to run a program or instructions to perform the first aspect or any possible implementation thereof, or to perform the methods described in the second aspect or any possible implementation thereof. The communication interface in the chip may be an input / output interface, a pin, or a circuit, etc.

[0071] In one possible implementation, the chip or chip system described above in this application further includes at least one memory, in which programs or instructions are stored. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0072] The seventh aspect provides a readable storage medium (also referred to as a computer-readable storage medium) storing a program or instructions that, when executed on an electronic device, cause the electronic device to perform the first aspect or any possible implementation thereof, or to perform the method described in the second aspect or any possible implementation thereof.

[0073] The eighth aspect provides a program product (also referred to as a computer program product), the program product including a program or instructions that, when run on an electronic device, cause the electronic device to perform the first aspect or any possible implementation thereof, or to perform the method described in the second aspect or any possible implementation thereof.

[0074] It should be understood that the third to eighth aspects of this application correspond to the technical solutions of the first and second aspects of this application, and the beneficial effects obtained by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0075] Figure 1 This is a schematic diagram illustrating the verification of an application in an electronic device system, as provided in an embodiment of this application.

[0076] Figure 2 This is a functional schematic diagram of an intelligent driving device provided in an embodiment of this application;

[0077] Figure 3 A schematic diagram of a vehicle infotainment system architecture provided in an embodiment of this application;

[0078] Figure 4 This application provides a schematic diagram of the system architecture for a permission management method.

[0079] Figure 5 A schematic diagram of a key distribution stage provided for an embodiment of this application;

[0080] Figure 6 A flowchart illustrating the key negotiation stage and data encryption / decryption stage provided in this application embodiment;

[0081] Figure 7 A schematic diagram illustrating a permission management method provided in an embodiment of this application;

[0082] Figure 8 This is a schematic diagram of the structure of a chip provided in an embodiment of this application. Detailed Implementation

[0083] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms involved in the embodiments of this application will be briefly introduced below:

[0084] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with essentially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0085] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0086] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0087] In some implementations, electronic devices can perform application identification and interface access control based on application signatures. If the application signature verification passes, the application can access system resources within the electronic device. These system resources include, for example, microphone data, speaker data, camera data, display data, and sensor data.

[0088] For example, such as Figure 1 As shown in (a), applications (such as Application A and Application B) can apply for application permissions from the authorization center and obtain their respective signing certificates before release. It can be understood that the application's signing certificate is a certificate signed by the developer's private key, used to uniquely identify the application. The application's signing certificate includes the certificate's public key and the application's identity information (such as the developer's name). When an electronic device system installs an application, the system can verify the application's signature based on the certificate's public key. If the application signature verification passes, the electronic device system can install the application. Applications can access system resources by requesting user authorization or system-level permissions. System-level permissions can be understood as non-sensitive permissions, permissions that do not require manual user authorization. System-level permissions are only granted to applications with the same system signature, such as system applications.

[0089] However, the aforementioned access control methods lack fine-grained control over application identity and access permissions. In the in-vehicle infotainment system ecosystem, this can easily lead to security risks such as application abuse of system permissions and unauthorized access to data.

[0090] In some scenarios, such as Figure 1 As shown in (b), the various system resources in an electronic device can be managed by a unified service (referred to as the System Resource Management Service). However, the application's certificate public key is not disclosed to third-party applications or services (such as the System Resource Management Service). Only the electronic device can use the certificate public key to verify the application signature, thereby authenticating the application. Furthermore, considering application security, the electronic device will not disclose the application's verification results (such as information including the developer's name and application source), preventing third-party applications or services from obtaining the application's signature information and verifying its source. This can also be understood as... Figure 1 In (b), the application signature cannot provide a trusted or verifiable application identity and assertion. The system resource management service deems the application identity untrustworthy and therefore cannot authorize based on a trusted application identity. This prevents trusted communication and data sharing between the system resource management service and the application, resulting in the application being unable to access system resources.

[0091] Furthermore, in some implementations, multiple system applications use the same key for signing, making it impossible for the electronic device system to distinguish the identities of these applications. This prevents the electronic device system from controlling access permissions for each application individually, forcing it to grant permissions uniformly to all system applications in a coarse-grained manner. This weakens the electronic device's ability to minimize the granting of system resources.

[0092] In view of this, the permission management method provided in this application embodiment allows the electronic device system to pre-install an authorization center root certificate, establishing a trusted chain of trust. Applications can apply for system-wide permission certificates from the electronic device system based on the certificate obtained from the authorization center (referred to as the initial permission certificate). In this way, services in the electronic device system (such as system resource management services) can authenticate and control applications based on the system-wide permission certificates. This enables the construction of a secure and controllable permission management system in the electronic device system, achieving application authentication and fine-grained permission management.

[0093] It is understood that the electronic device in the embodiments of this application can also be any form of terminal device. For example, electronic devices may include: mobile phones, tablets, PDAs, laptops, mobile internet devices (MIDs), wearable devices, smart driving devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, electronic devices in 5G networks, or future evolution of public land mobile communication networks. The embodiments of this application do not limit the scope of electronic devices in a network (PLMN).

[0094] Furthermore, in this application embodiment, the electronic device can also be an electronic device in the Internet of Things (IoT) system. IoT is an important part of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0095] For ease of description, the following description uses electronic devices as examples of intelligent driving devices. It is understood that intelligent driving devices may have corresponding vehicle infotainment systems, in which a permission management system can be built to execute the permission management methods of the embodiments of this application.

[0096] For example, Figure 2 A functional schematic diagram of an intelligent driving device provided in an embodiment of this application is shown.

[0097] like Figure 2 As shown, the intelligent driving device 200 may include a perception system 210, a display device 220, and a computing platform 230. The perception system 210 may include several sensors for sensing information about the surrounding environment of the intelligent driving device 200. For example, the perception system 210 may include a positioning system, which can be a global navigation satellite system (GNSS), such as the Global Positioning System (GPS) or the BeiDou Navigation Satellite System (BDS). As another example, the perception system 210 may also include one or more of the following: an inertial measurement unit (IMU), lidar, millimeter-wave radar, ultrasonic radar, and a camera device.

[0098] The display devices 220 within the cockpit of the intelligent driving equipment 200 are mainly divided into two categories: the first is in-vehicle displays; the second is projection displays, such as head-up displays (HUDs). In-vehicle displays are physical displays and an important component of in-vehicle infotainment systems. Multiple displays can be installed in the cockpit, such as digital instrument cluster displays and central control screens. In some possible implementations, one or more of the aforementioned in-vehicle displays can be human-machine interfaces (HMIs), for example, the central control screen can be an HMI. Head-up displays, also known as head-up display systems, are mainly used to display driving information such as speed and navigation on a display device in front of the driver (e.g., on the windshield). This reduces driver eye movement time, avoids pupil changes caused by eye movement, and improves driving safety and comfort.

[0099] Some or all of the functions of the intelligent driving device 200 can be controlled by the computing platform 230. The computing platform 230 may include processors 231 to 23n, which are circuits with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a type of microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits, where these logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field-programmable gate array (FPGA). In reconfigurable hardware circuits, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement some or all of the functions of the aforementioned units. Furthermore, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc. In addition, the computing platform 230 may also include a memory for storing instructions. Some or all of the processors 231 to 23n can call the instructions in the memory to implement the corresponding functions.

[0100] The computing platform 230 controls the operation of the vehicle's infotainment system, which may include an advanced driving assistance system (ADAS) and an autonomous driving system (ADS). The infotainment system utilizes various sensors on the vehicle (including but not limited to: LiDAR, millimeter-wave radar, cameras, ultrasonic sensors, GPS, and inertial measurement units) to acquire information from the vehicle's surroundings and analyzes and processes this information. This enables functions such as obstacle perception, target recognition, vehicle localization, path planning, and driver monitoring / alerts, thereby improving the safety, automation, and comfort of driving.

[0101] Figure 3 A schematic diagram of a vehicle infotainment system architecture provided in an embodiment of this application is shown.

[0102] like Figure 3 As shown, the vehicle infotainment system 300 includes a perception module 310, a human-machine interaction module 320, a display module 330, and a control module 340.

[0103] The sensing module 310 may include Figure 2 The perception system 210 shown includes one or more camera devices or one or more radar sensors for collecting environmental information about the area where the vehicle is located, such as parking line information and obstacle information. The perception module 310 can also process the collected environmental information to create a world model of roads, obstacles, etc., for downstream modules (such as the human-machine interaction module 320, control module 340, etc.). The perception module 310 can send the collected and / or determined information to the control module 340.

[0104] The human-computer interaction module 320 may include Figure 2 One or more of the display devices 220 shown may include, for example, an HMI. The human-computer interaction module 320 may also include a sound-generating device (such as a speaker, audio jack, etc.) and a sound-receiving device (such as a microphone). The display module 330 may include... Figure 2 One or more of the display devices 220 shown are configured to display a vehicle infotainment system interface. The human-machine interface module 330 can receive user commands (including voice commands, touchscreen commands, etc.) and then control the changes of the interface displayed by the display module 330 according to the commands.

[0105] In this embodiment of the application, the control module 340 may include an in-vehicle service 341 and a safety subsystem 342.

[0106] In-vehicle service 341 can act as a data provider for the vehicle infotainment system, responsible for enforcing access control policies so that access to system resources by various applications or modules is controlled.

[0107] In-vehicle services 341 may include an in-vehicle infotainment API gateway (IVI API GW), which may also be called an in-vehicle computing center.

[0108] This in-vehicle computing center serves as a secure channel for acquiring system resource data, enabling the processing and encapsulation of this data. System resource data may include, but is not limited to, one or more of the following: vehicle status data (such as door lock status, window closed status, etc.), vehicle control data (such as control of windows, seats, trunk, etc.), vehicle location data, user biometric data (such as user voiceprint, fingerprint, facial features, etc.), audio data (such as microphone data, speaker data, etc.), image data (such as data captured by cameras, data displayed on the screen, etc.), and various sensor data.

[0109] The onboard computing center can also be responsible for receiving requests from applications or modules and verifying the legality of the requests, thereby determining whether to allow applications or modules to access system resource data.

[0110] The security subsystem may include an in-vehicle miniature certificate authority (In-Vehicle miniCA), also known as the in-vehicle access control center.

[0111] The in-vehicle access control center is the core of the vehicle infotainment system's trust architecture, responsible for issuing and managing certificates within the system. Its main responsibilities include:

[0112] The in-vehicle access control center can pre-install the application permission root certificate of the external application permission authorization center (hereinafter referred to as the external authorization center). Before the car leaves the factory, the application permission root certificate of the external authorization center can be pre-installed in the in-vehicle access control center to establish a trust foundation for the vehicle system.

[0113] The in-vehicle access control center can also issue service certificates (or process certificates) for in-vehicle services. When an in-vehicle service is first started, it can apply to the in-vehicle access control center for the issuance or renewal of a service certificate. The in-vehicle access control center can then issue a certificate to the in-vehicle service to identify its identity, serving as the "digital identity" of the in-vehicle service in the vehicle's infotainment system.

[0114] The in-vehicle access control center can also issue in-vehicle access certificates for applications. When an application needs to access in-vehicle system resources, it can apply for an in-vehicle access certificate from the in-vehicle access control center. The in-vehicle access control center will verify the application's initial access certificate, which is issued by the external authorization center. Based on the scope of permissions in the initial access certificate, the in-vehicle access control center will also issue an in-vehicle access certificate to the application that is limited to accessing system resources within the scope of permissions.

[0115] The methods of this application will be described in detail below through specific embodiments. The following embodiments can be combined with each other or implemented independently, and the same or similar concepts or processes may not be described again in some embodiments.

[0116] For example, such as Figure 4 The diagram shown is a system architecture diagram of the permission management method according to an embodiment of this application.

[0117] This system architecture can include an external authorization center, an in-vehicle access control center, in-vehicle services, and in-vehicle applications. For a description of the in-vehicle access control center and in-vehicle services, please refer to [link to relevant documentation]. Figure 3 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0118] The external authorization center acts as the source for application permission management, responsible for managing application registration, identity, and permission requests. Application developers or operators can submit permission requests for the required permissions to the external authorization center. After approval, the external authorization center can issue an initial permission certificate to the application. This initial permission certificate serves as the application's identity verification within the vehicle's infotainment system and is also the credential for subsequent permission requests to the in-vehicle permission management center. The permissions requested by the application may include, but are not limited to, system permissions (such as voice control permissions, permissions to access vehicle information, etc.), communication permissions (such as network permissions, Bluetooth permissions, telephone permissions, etc.), and data permissions (such as location permissions, contact permissions, storage permissions, etc.), etc., which are not limited in this embodiment.

[0119] In-vehicle applications can include system applications and third-party applications. For example... Figure 4 As shown, in-vehicle applications may include application A and application B. The following uses application A as an example to illustrate the permission management method of this application embodiment.

[0120] In this embodiment of the application, the access control method may include the following steps S401 to S407. The execution order of each step is not limited, as long as the access control method can be implemented. Each step is described below.

[0121] S401, The application requests permissions from the external authorization center.

[0122] Understandably, before an application is released, the application developer or operator can submit a permission request for the required permissions to the external authorization center. After the external authorization center approves the application, it can use the private key root_sk to sign the application permissions and issue an initial permission certificate to the application. After obtaining the initial permission certificate, the application developer or operator can package the initial permission certificate into the application package and release it to an app store or pre-install it on electronic devices (such as intelligent driving devices).

[0123] The initial authorization certificate may include signature information obtained by the external authorization center using the private key root_sk to sign the application identity credentials and the application permission scope. The application identity credentials can have different representations.

[0124] In one possible implementation, the application identity credential can be the application public key. For example, the external authorization center can generate an application public key `app_pk1` and an application private key `app_sk1` for application A, and use the application public key `app_pk1` as the application identity credential. Alternatively, application A can generate its own application public key `app_pk1` and application private key `app_sk1`. When application A submits a permission request to the external authorization center, application A can include the application public key `app_pk1`, thus using `app_pk1` as the application identity credential. It is understood that different applications have their own corresponding application public key and application private key. For example, application B can have a corresponding application public key `appB_pk1` and application private key `appB_sk1`.

[0125] In another possible implementation, the application identity credential can be the application's identifier (ID) information. The application ID information can be a hash value obtained by hashing the application package (APK), an application identifier (AppID), or other identification information; this application embodiment does not limit this. For example, application A can have a corresponding appA_ID, and application B can have a corresponding appB_ID.

[0126] In another possible implementation, application identity credentials can be represented by a combination of application public key and application ID information, which is a combination of the two implementation methods mentioned above.

[0127] The application permission scope can also be called the initial permission scope. The initial permission scope indicates which permissions of the application have been controlled and authorized by the external authorization center.

[0128] Understandably, the initial permission certificate ensures the legitimacy of the application. The in-vehicle permission management center can verify the signature of the external authorization center to confirm that the application's initial permission certificate was issued by the external authorization center, thereby establishing a trusted application identity and determining the application's permission scope.

[0129] S402, In-vehicle service initialization.

[0130] When an in-vehicle service is first activated, it can send a request to the in-vehicle access control center to obtain a service certificate. It is understood that the initial activation of an in-vehicle service can occur either at the zero-kilometer stage of the vehicle production line or during the initial use of the vehicle; there are no restrictions.

[0131] The in-vehicle access control center can verify the identity of in-vehicle services based on a system service whitelist. If the in-vehicle service identity verification is successful, the in-vehicle access control center can return a service certificate to the in-vehicle service. This service certificate can be, for example, an X.509 digital certificate, without limitation. The service certificate includes the signature information of the in-vehicle access control center using its own private key to sign the in-vehicle service public key srv_pk, and the root certificate of the in-vehicle access control center. The root certificate of the in-vehicle access control center carries its public key. The in-vehicle service public key srv_pk can serve as the identity credential of the in-vehicle service. Subsequently, when the in-vehicle service interacts with applications, the in-vehicle service can exchange its in-vehicle service public key srv_pk with the application to identify its identity. The application can generate a working key (also called a session key or symmetric key) based on the in-vehicle service public key srv_pk to encrypt or decrypt business data.

[0132] In one possible implementation, the in-vehicle service can generate an in-vehicle service public key (srv_pk) and an in-vehicle service private key (srv_sk). When the in-vehicle service sends a request to the in-vehicle access control center, it can send the in-vehicle service public key (srv_pk) to the center. Understandably, the in-vehicle service private key (srv_sk) is stored and managed by the in-vehicle service itself.

[0133] In another possible implementation, the in-vehicle access control center can generate an in-vehicle service public key (srv_pk) and an in-vehicle service private key (srv_sk) for the in-vehicle service. It is understood that the in-vehicle service private key (srv_sk) can be stored and managed by the in-vehicle access control center, or by the in-vehicle service itself.

[0134] The in-vehicle service private key, srv_sk, is stored and managed by the in-vehicle permission management center. This can be understood as the in-vehicle permission management center hosting the in-vehicle service private key. The in-vehicle permission management center has the ability to control the permissions of in-vehicle services. Since in-vehicle services cannot obtain their own private key, srv_sk, when they need to authorize other applications or services to grant their own permissions, the in-vehicle service needs to be signed by the in-vehicle permission management center.

[0135] The in-vehicle service private key srv_sk is stored and managed by the in-vehicle service. This means that after generating the in-vehicle service private key srv_sk, the in-vehicle access control center can synchronize the srv_sk to the in-vehicle service. This gives the in-vehicle service its own signing capability, i.e., the ability to control in-vehicle service permissions, allowing it to authorize other applications or services with its own permissions. It can be understood that the in-vehicle access control center can synchronize the srv_sk to the in-vehicle service when returning the service certificate, or it can synchronize the srv_sk to the in-vehicle service separately; there is no limitation on this.

[0136] Optionally, the in-vehicle service can also obtain the in-vehicle access control center's signature root certificate. This signature root certificate is used to verify the application's in-vehicle access control certificate. The signature root certificate may carry the in-vehicle access control center's public key, miniCA_pk.

[0137] Understandably, step S402 establishes a trusted identity for the in-vehicle service.

[0138] S403, Application A requests permissions from the in-vehicle permission management center.

[0139] When application A needs to access the vehicle's system resources, application A will send a request to the vehicle's access control center with its initial permission certificate.

[0140] In one possible implementation, taking application A's application identity credential as the application public key appA_pk1 as an example, the initial permission certificate obtained by application A from the external authorization center can be represented as Cert1(appA_pk1, initial permission scope). Alternatively, the initial permission certificate can be understood as the signature information obtained by the external authorization center using its private key root_sk to sign the application identity credential and the initial permission scope. This initial permission certificate can be in the form of an X.509 digital certificate.

[0141] Application A can send a request to the in-vehicle access control center, which may include an initial access certificate. Based on the initial access certificate, the in-vehicle access control center can issue an in-vehicle access certificate to application A with a self-signed signature (such as using the in-vehicle access control center's private key miniCA_sk as described below), denoted as Cert2(appA_pk2, initial access range). Here, appA_pk1 and appA_pk2 can be the same or different, without limitation.

[0142] In another possible implementation, application A can request an initial scope of permissions from an external authorization center. After approval, the external authorization center can sign the initial scope of permissions using its private key `root_sk`, obtaining the signature information `Sign(root_sk, initial scope of permissions)`, and send this signature information to application A. Application A can generate a public-private key pair and use its application private key (denoted as `appA_sk3`) to sign its application public key (denoted as `appA_pk3`) and the signature information `Sign(root_sk, initial scope of permissions)`, generating a certificate signing request (CSR) file, denoted as `CSR(appA_pk3, initial scope of permissions)`. This CSR file can comply with Certificate Management Protocol version 2 (CMPv2).

[0143] Application A can send a request to the in-vehicle access control center, which may include the CSR file. Based on the CSR file, the in-vehicle access control center can issue an in-vehicle access certificate to application A with a self-signed signature (such as using the in-vehicle access control center's private key miniCA_sk as described below), denoted as Cert2(appA_pk4, initial access range). Here, appA_pk3 and appA_pk4 can be the same or different, without limitation.

[0144] S404, In-vehicle access control center verifies and issues certificates for application A.

[0145] Upon receiving a request from application A, the in-vehicle access control center can verify application A's initial access certificate. For example, the in-vehicle access control center may have a pre-installed root certificate (also known as rootCA) from an external authorization center. The in-vehicle access control center can use the public key root_pk of the root certificate to verify the private key root_sk of the initial access certificate, thereby determining the validity of application A's initial access certificate and confirming the trustworthiness of its origin.

[0146] If the initial access certificate verification passes, the in-vehicle access control center can issue an in-vehicle access certificate for application A. This in-vehicle access certificate can be, for example, an X.509 digital certificate, without limitation. The in-vehicle access certificate may include the signature information of the in-vehicle access control center and its public key, miniCA_pk. The private key corresponding to the public key miniCA_pk is miniCA_sk, and the signature information is the result of the in-vehicle access control center signing the application's identity credentials and initial access scope using the private key miniCA_sk.

[0147] In possible implementations, the signature information of the in-vehicle access control center can be implemented in several different ways:

[0148] Scenario 1: If the application identity credential in the initial permission certificate is the application public key app_pk1, then the in-vehicle permission management center can use the following implementation method for signing.

[0149] Implementation Method 1.1: The in-vehicle access control center can reuse the application public key app_pk1 (which can also be understood as the original public key). The in-vehicle access control center can use the private key miniCA_sk to sign the application public key app_pk1 and the initial access scope. It is understood that the application private key app_sk1 corresponding to the application public key app_pk1 is stored and managed by application A.

[0150] Implementation Method 1.2: Application A can generate a new application public key app_pk2 and an application private key app_sk2. When application A sends a request to the in-vehicle access control center, it can send the application public key app_pk2 to the center. The in-vehicle access control center can then use the private key miniCA_sk to sign the application public key app_pk2 and the initial access scope. It is understood that the application private key app_sk2 is stored and managed by application A.

[0151] Implementation Method 1.3: The in-vehicle access control center can generate a new application public key app_pk3 and application private key app_sk3 for application A. The in-vehicle access control center can then use its own private key miniCA_sk to sign the application public key app_pk3 and the initial access scope. It is understandable that the application private key app_sk3 can be stored and managed by the in-vehicle access control center or by application A.

[0152] The application private key app_sk3 is stored and managed by the in-vehicle permission management center, which can be understood as the in-vehicle permission management center hosting the application private key. The in-vehicle permission management center has the ability to control the permissions of application A. Since application A cannot obtain the application private key app_sk3, when it needs to authorize its own permissions to other applications or services, application A needs to sign through the in-vehicle permission management center.

[0153] The application private key app_sk3 is stored and managed by application A. This means that after generating the application private key app_sk3, the in-vehicle access control center can synchronize the application private key app_sk3 to application A. In this way, application A has the ability to sign documents, i.e., the ability to control permissions, and can authorize other applications or services with its own permissions. It can be understood that the in-vehicle access control center can synchronize the application private key app_sk3 to application A when returning the in-vehicle access certificate to the application, or it can synchronize the application private key app_sk3 to application A separately; there is no limitation on this.

[0154] Scenario 2: If the application identity credential in the initial permission certificate is the application's ID information, the in-vehicle permission management center can use the above implementation method 1.2 or implementation method 1.3 for signing, which will not be elaborated further.

[0155] S405, In-vehicle services authenticate and verify the identity and permissions of application A.

[0156] After application A obtains the in-vehicle access certificate, it can send the certificate and its identity credentials to the in-vehicle service. The in-vehicle service can then verify application A's identity credentials and the permissions requested.

[0157] In one possible implementation of identity authentication, the in-vehicle service can verify the in-vehicle permission certificate of application A based on the in-vehicle permission management center signature root certificate obtained in step S402. For example, the in-vehicle service can verify the in-vehicle permission management center's private key miniCA_sk in the in-vehicle permission certificate using the public key miniCA_pk of the in-vehicle permission management center signature root certificate.

[0158] In another possible implementation of identity authentication, if the in-vehicle service does not obtain the signature root certificate of the in-vehicle permission management center, the in-vehicle service can send the in-vehicle permission certificate of application A to the in-vehicle permission management center, which will then verify the in-vehicle permission certificate of application A.

[0159] Once the identity of application A is verified as trustworthy, the in-vehicle service can further verify the permissions that application A is requesting to access. Based on the in-vehicle permission certificate submitted by application A, the in-vehicle service can execute access control policies and check whether the initial permission scope in the certificate includes the permissions that application A is requesting. If the initial permission scope includes the permissions that application A is requesting, it means that application A has the permission to request system resources, and the permission verification passes. If the initial permission scope does not include the permissions that application A is requesting, it means that application A does not have the permission to request system resources, and the permission verification fails.

[0160] If both the identity credentials of application A and the permissions requested for this access are verified, the in-vehicle service can allow application A to access the system resources corresponding to its access permissions.

[0161] Understandably, since application B has not applied for an in-vehicle permission certificate from the in-vehicle permission management center, the in-vehicle service's authentication and permission verification of application B will fail, and the in-vehicle service can deny application B access to system resources. Optionally, the in-vehicle service can also return an error message to application B indicating that access to system resources failed. This error message can be used to indicate that application B's authentication and / or permission verification failed.

[0162] S406, in-vehicle services and applications transmit data.

[0163] If both the identity credentials of application A and the access permissions requested are verified, the in-vehicle service and application A can transmit data.

[0164] In a possible implementation, the business service and application A can generate a working key using a key negotiation algorithm based on each other's public key and their own private key. This working key is used to encrypt or decrypt data. For example, the key negotiation algorithm could include elliptic curve difficulty-Hellman key exchange (ECDH). Because other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus improving the security of data transmission.

[0165] It is understood that, in this embodiment, the in-vehicle access control center can manage the certificate lifecycle of in-vehicle services and applications (including certificate issuance, renewal, revocation, etc.), improving the security of accessing system data and preventing unauthorized access or tampering of system data by applications. Furthermore, in-vehicle services enable centralized and standardized access control of system resources, allowing for fine-grained management of application authentication and permissions, thereby enhancing the security of the vehicle system.

[0166] The following is through Figure 5 and Figure 6 The flowchart illustrates the key interaction process between the in-vehicle access control center, in-vehicle services, and applications.

[0167] The interaction process can include (1) a key distribution phase, (2) a key negotiation phase, and (3) a data encryption / decryption phase. Specifically, (1) the key distribution phase is used to establish a secure communication foundation for the application and in-vehicle services, obtaining certificates and keys for data encryption / decryption. (2) the key negotiation phase is used to securely negotiate working keys for data encryption / decryption between the application and in-vehicle services. (3) the data encryption / decryption phase corresponds to the data transmission process; the working key ensures that the data is encrypted and secure during transmission. Each phase is explained below.

[0168] (1) Key distribution stage.

[0169] For example, such as Figure 5 The diagram illustrates the key distribution process. This key distribution process can include a key distribution stage for applications and a key distribution stage for in-vehicle services. In this embodiment, the execution order of the steps in the key distribution stages for applications and in-vehicle services is not limited, as long as the access control method can be implemented. The key distribution stage for applications mainly includes steps S503 to S508, and the key distribution stage for in-vehicle services includes steps S509 to S514, which will be described in detail below.

[0170] (a) The key distribution phase of the application.

[0171] S501. The application requests application permissions from the external authorization center and obtains the initial permission certificate.

[0172] S502, the external authorization center returns the initial permission certificate to the application.

[0173] Understandably, before the application's key distribution phase, the application needs to execute step S501 to request application permissions from the external authorization center and obtain an initial permission certificate. The external authorization center can then execute step S502 to return the initial permission certificate to the application. The specific process can be found in [reference needed]. Figure 4 The relevant descriptions in step S401 of the corresponding embodiment will not be repeated here.

[0174] S503. The application requests its public and private key pair from the key management service (KMS).

[0175] S504, The key management service generates public and private key pairs for the application.

[0176] S505, The key management service returns the application's public key.

[0177] Key management services are used to securely store, manage, and distribute encryption keys, ensuring the confidentiality, integrity, and availability of data during transmission and storage.

[0178] In this embodiment, the application can request its public-private key pair from the key management service. Based on the application's request, the key management service can generate the application's public-private key pair (app_pk, app_sk). For the generated public-private key pair, on the one hand, the key management service can execute step S505, returning the application's public key app_sk to the application. On the other hand, the key management service can securely store the application's private key app_pk.

[0179] S506. The application carries the initial permission certificate and requests the in-vehicle permission certificate from the in-vehicle permission management center.

[0180] S507. The in-vehicle permission management center verifies the initial permission certificate of the application and issues an in-vehicle permission certificate.

[0181] S508, the in-vehicle permission management center returns the in-vehicle permission certificate to the application.

[0182] The application can also carry an initial permission certificate to request an in-vehicle permission certificate from the in-vehicle permission management center. For details, please refer to [link / reference]. Figure 4 The relevant descriptions in step S403 of the corresponding embodiment will not be repeated here.

[0183] The in-vehicle access control center can verify the initial access certificate. If the verification passes, the in-vehicle access control center can issue an in-vehicle access certificate for the application. This in-vehicle access certificate includes the application's public key (app_pk) and initial permissions, among other information. For details, please refer to [link / reference needed]. Figure 4 The relevant descriptions in step S404 of the corresponding embodiment will not be repeated. It is understood that, taking application A as an example, the application public key app_pk can be the application public key app_pk1 in the initial permission certificate, the application public key app_pk2 newly generated by the application, or the application public key app_pk3 newly generated by the in-vehicle permission management center. This application embodiment does not limit the scope.

[0184] The in-vehicle access control center can return in-vehicle access certificates and its own root certificate to applications. This root certificate carries the in-vehicle access control center's public key, miniCA_pk. This root certificate can be understood as a trust anchor between the application and in-vehicle services, facilitating subsequent business data interaction.

[0185] It is understood that there is no distinction in the execution order between steps S503 to S505 and steps S506 to S508. That is, the interaction process between the application and the key management service and the interaction process between the application and the in-vehicle permission management center do not have a distinction in the execution order, as long as the permission management method of this application embodiment can be implemented.

[0186] (b) Key distribution phase for in-vehicle services.

[0187] S509. The in-vehicle service requests the public and private key pair of the in-vehicle service from the key management service.

[0188] S510, Key Management Service generates public and private key pairs for in-vehicle services.

[0189] S511, Key Management Service returns the public key for in-vehicle services.

[0190] The in-vehicle service can request a public-private key pair from the key management service. Based on the request, the key management service can generate a public-private key pair (srv_pk, srv_sk) for the in-vehicle service. For the generated public-private key pair, the key management service can, on the one hand, execute step S511 to return the public key srv_sk to the in-vehicle service. On the other hand, the key management service can securely store the private key srv_pk of the in-vehicle service.

[0191] S512, In-vehicle services request service certificates from the in-vehicle access control center.

[0192] S513. The in-vehicle access control center verifies the identity of the in-vehicle service and issues a service certificate.

[0193] S514, The in-vehicle access control center returns the service certificate to the in-vehicle service.

[0194] In-vehicle services can also apply for service certificates from the in-vehicle access control center. The in-vehicle access control center can verify the identity of the in-vehicle service. If the verification is successful, the in-vehicle access control center can issue a service certificate cert(srv_pk) containing the in-vehicle service's public key srv_pk. For details, please refer to [link to documentation / reference]. Figure 4 The relevant descriptions in step S402 of the corresponding embodiment will not be repeated here.

[0195] The in-vehicle access control center can return a service certificate and the root certificate of the in-vehicle access control center to the in-vehicle service. The root certificate carries the public key miniCA_pk of the in-vehicle access control center.

[0196] It is understood that there is no distinction in the execution order between steps S509 to S511 and steps S512 to S514. That is, the interaction process between the in-vehicle service and the key management service, and the interaction process between the in-vehicle service and the in-vehicle permission management center, do not have a distinction in the execution order, as long as the permission management method of this application embodiment can be implemented.

[0197] The following is through Figure 6 The procedures for (2) key negotiation stage and (3) data encryption / decryption stage are described in detail. The (2) key negotiation stage includes the following steps S601 to S608, and the (3) data encryption / decryption stage includes the following steps S609 to S614.

[0198] (2) Key negotiation phase.

[0199] In a possible implementation, applications and in-vehicle services can generate and manage working keys for interaction between them based on a key management service. In-vehicle services and applications can exchange their public keys and use a key negotiation algorithm to generate a shared working key. Understandably, for the security of key negotiation, both the in-vehicle service and the application will initiate a request to the key management service, which will then assist in completing the key negotiation process and generating a secure working key pair.

[0200] S601, The application sends the application public key to the in-vehicle service.

[0201] S602, In-vehicle services negotiate service keys based on key management services.

[0202] S603, Key Management Service generates working keys for in-vehicle services.

[0203] S604. The key management service returns a message indicating successful key negotiation to the in-vehicle service.

[0204] S605. The in-vehicle service returns its public key to the application. For example, the application can send its public key app_pk to the in-vehicle service. The in-vehicle service can then send its public key app_pk to the key management service for service key negotiation. Specifically, the key management service can generate a working key SRV_APP_KEY corresponding to the in-vehicle service based on the stored private key srv_sk of the in-vehicle service and the application public key app_pk.

[0205] Among them, the in-vehicle service private key srv_sk is the private key corresponding to the in-vehicle service public key srv_pk. The public-private key pair of the in-vehicle service is generated by the key management service in step S510 above. It can be understood that, taking application A as an example, as described in (1), the application public key app_pk can be application public key app_pk1, application public key app_pk2, or application public key app_pk3, without limitation.

[0206] After the key management service generates the working key for the in-vehicle service, it can return a message indicating successful key negotiation to the in-vehicle service. Based on this message, the in-vehicle service can return its public key, srv_pk, to the application. Optionally, the key management service can also return the service's working key, SRV_APP_KEY, to the in-vehicle service; this is not limited.

[0207] S606. Applications negotiate application keys based on key management services.

[0208] S607, Key Management Service generates working keys for applications.

[0209] S608. The key management service returns a message indicating successful key negotiation to the application. Applications can also perform application key negotiation based on the key management service. An application can send the in-vehicle service's public key srv_pk to the key management service to perform application key negotiation. Specifically, the key management service can generate the application's corresponding working key APP_SRV_KEY based on the stored application private key app_sk and the in-vehicle service's public key srv_pk.

[0210] Here, the application private key app_sk is the private key corresponding to the application public key app_pk. The application's public-private key pair is generated by the key management service in step S504 above. For example, if the application public key is app_pk1, then the application private key is app_sk1; if the application public key is app_pk2, then the application private key is app_sk2; if the application public key is app_pk3, then the application private key is app_sk3.

[0211] After the key management service generates the application's working key, it can return a message indicating successful key negotiation to the application. Then, the application and in-vehicle services can interact based on their respective working keys. Optionally, the key management service can also return the application's working key, APP_SRV_KEY, to the application; this is not limited.

[0212] It is understandable that the working key SRV_APP_KEY for in-vehicle services and the working key APP_SRV_KEY for applications have the same value, but the holders are different.

[0213] (3) Data encryption and decryption stage.

[0214] S609, The application sends a data request to the in-vehicle service.

[0215] S610, in-vehicle services encrypt data based on key management service.

[0216] S611, The key management service returns encrypted data to the in-vehicle service.

[0217] S612, In-vehicle services return encrypted data to applications.

[0218] For example, when an application requests system resources from an in-vehicle service, the application can send a data request to the in-vehicle service. The in-vehicle service can encrypt the data based on a key management service. Specifically, the key management service can use the in-vehicle service's working key SRV_APP_KEY to encrypt system resource data, generating encrypted data (also known as ciphertext data), and return the encrypted data to the in-vehicle service. The in-vehicle service can then return the encrypted data to the application.

[0219] S613, The application uses key management services to decrypt data.

[0220] S614, The key management service returns decrypted data to the application.

[0221] After obtaining the encrypted data, the application can decrypt it using the key management service. Specifically, the key management service can use the application's working key APP_SRV_KEY to decrypt the encrypted data, thereby restoring the original plaintext data. Then, the key management service can return the decrypted data to the application.

[0222] Understandably, through Figure 5 and Figure 6 The key exchange process shown enhances the confidentiality and integrity of data during cross-process transmission. Even if data is intercepted by other applications or services, they will not be able to decrypt it.

[0223] Figure 7 This application illustrates a permission management method according to an embodiment of the present application. The method includes:

[0224] S701. If the first module of the electronic device passes the verification of the first application of the electronic device, the first module sends the first certificate to the first application.

[0225] The electronic device can be any form of terminal device, without limitation. For ease of description, the following explanation will still use an intelligent driving device as an example. This intelligent driving device includes a vehicle-mounted system, in which a permission management system can be built to execute the permission management method of the embodiments of this application.

[0226] The first module can be understood as the in-vehicle access control center mentioned above. It is the core of the vehicle's infotainment system's trust architecture, responsible for issuing and managing certificates within the system. For a detailed explanation of the first module, please refer to [link to relevant documentation]. Figure 3 The description of the in-vehicle access control center in the corresponding embodiment will not be repeated here.

[0227] The first application can be any application in the electronic device, such as application A in the above text.

[0228] The first certificate can be understood as the in-vehicle access certificate mentioned above, which is issued by the in-vehicle access management center. For details on the first module's verification process for the first application, and an explanation of the first certificate, please refer to [link to relevant documentation]. Figure 4 The relevant descriptions in step S404 of the corresponding embodiment will not be repeated here.

[0229] S702. The first service of the electronic device obtains first information of the first application, the first information being used to request business interaction with the first service, the first information including the first certificate.

[0230] The first service can be understood as the in-vehicle service mentioned above. The first service acts as the data provider for the vehicle's infotainment system, responsible for enforcing access control policies to ensure that access to system resources by various applications or modules is managed. The first service may include the In-Vehicle Computing Center (IVI API GW). For a detailed explanation of the In-Vehicle Computing Center, please refer to [link to relevant documentation]. Figure 3 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0231] When a first application wants to access the system resources of the vehicle infotainment system through a first service, the first application can send first information to the first service. This first information may include a first certificate and the permissions the first application wishes to access. The in-vehicle service can then execute step S703 to verify the first certificate and the requested permissions.

[0232] S703, The first service verifies the first certificate.

[0233] For details on the process of the first service verifying the first certificate, please refer to [link / reference]. Figure 4 The relevant descriptions in step S405 of the corresponding embodiment will not be repeated here.

[0234] S704. If the first certificate verification is successful, the first service and the first application shall conduct business interactions.

[0235] Once the first service verifies the first certificate, it engages in business interactions with the first application, allowing the first application to access system resources. For details on the data interaction process between the first service and the first application, please refer to [link / reference needed]. Figure 4 The relevant descriptions in step S406 of the corresponding embodiment will not be repeated here.

[0236] In this embodiment, the service in the vehicle infotainment system (corresponding to the first service) can authenticate and control the application (corresponding to the first application) based on the system's internal permission certificate (corresponding to the first certificate). This allows the vehicle infotainment system to build a secure and controllable permission management system, enabling application authentication and fine-grained permission management.

[0237] Optional, in Figure 7 Based on the corresponding embodiments, before the first module sends the first certificate to the first application after the first module of the electronic device has passed the verification of the first application of the electronic device, the method may further include: the first module obtaining second information of the first application, the second information including the first signature information of the authorization center; the first module verifying the first signature information; and the first module sending the first certificate to the first application after the first module of the electronic device has passed the verification of the first application of the electronic device, which may include: the first module sending the first certificate to the first application after the first signature information has passed the verification.

[0238] The second piece of information may include a first certificate (i.e., an initial authorization certificate), which includes the first signature information of the authorization center. This authorization center can be understood as the external authorization center mentioned above.

[0239] The first signature information can be understood as the signature information obtained by the authorization center using its own private key (such as root_sk in the above text) to sign the identity credentials and permission scope of the first application.

[0240] Understandably, the vehicle infotainment system can have a pre-installed root certificate from the authorization center, allowing the first module to verify the first signature information based on this root certificate. For details on the first module's verification process for the first signature information, please refer to... Figure 4 The relevant descriptions in step S404 of the corresponding embodiment will not be repeated here.

[0241] In this embodiment, the vehicle infotainment system establishes a trusted chain of trust between the external authorization center and the in-vehicle permission management center through a pre-installed root certificate of the authorization center. Applications, based on the certificate obtained from the external authorization center (corresponding to the initial permission certificate mentioned above), apply to the vehicle infotainment system for a first certificate within the system (corresponding to the in-vehicle permission certificate mentioned above). In this way, services in the vehicle infotainment system (such as the first service) can authenticate and control access to the first application based on the first certificate, thereby enabling the construction of a secure and controllable permission management system within the vehicle infotainment system, achieving application identity authentication and fine-grained permission management.

[0242] Optional, in Figure 7Based on the corresponding embodiment, the first signature information is the signature information obtained by signing the identity credentials and permission scope of the first application based on the first private key of the authorization center.

[0243] The first private key can be understood as the private key root_sk of the external authorization center mentioned above. The public key of the external authorization center corresponding to this first private key can be the public key root_pk mentioned above.

[0244] It is understandable that the identity credentials of the first application can have different representations. For example, the identity credentials of the first application may include the public key of the first application and / or the ID information of the first application. For a detailed explanation of application identity credentials, please refer to [link / reference needed]. Figure 4 The relevant descriptions in step S401 of the corresponding embodiment will not be repeated here.

[0245] The scope of permissions can be understood as the initial scope of permissions mentioned above. This initial scope of permissions indicates which permissions the external authorization center has controlled and authorized for the application.

[0246] Understandably, the initial permission certificate ensures the legitimacy of the application. In this embodiment, the in-vehicle permission management center can verify the signature of the external authorization center to confirm that the application's initial permission certificate was issued by the external authorization center, thereby establishing a trusted application identity and determining the application's permission scope.

[0247] Optional, in Figure 7 Based on the corresponding embodiments, the identity credentials of the first application include a second public key, which is generated by the authorization center or by the first application; and / or, the identity credentials of the first application include a first value, which is a hash value obtained by hashing the application package of the first application.

[0248] It is understandable that the identity credentials of the first application may include the public key of the first application and / or the ID information of the first application. For a detailed explanation of application identity credentials, please refer to [link / reference needed]. Figure 4 The relevant descriptions in step S401 of the corresponding embodiment will not be repeated here.

[0249] Taking application A (mentioned above) as an example, the second public key is the application public key app_pk1. This second public key can be generated by the external authorization center for application A, or it can be generated by the application itself; there is no limitation. The application private key corresponding to this second public key can be app_sk1 mentioned above.

[0250] In this embodiment, the identity credentials of the first application can have different representation methods. The vehicle system can flexibly select different representation methods according to specific circumstances such as security requirements, scenario convenience, or device capabilities, thereby expanding the feasibility of the access control scheme.

[0251] Optional, in Figure 7 Based on the corresponding embodiments, the first module is pre-configured with a first public key of the authorization center corresponding to the first private key; the first module verifies the first signature information, which may include: the first module verifies the first signature information based on the first public key; if the first signature information is verified successfully, the first module sends the first certificate to the first application, which may include: if the first module successfully decrypts the first signature information based on the first public key, the first module sends the first certificate to the first application.

[0252] The first public key can be understood as the public key root_pk of the external authorization center. For example, the first module (i.e., the in-vehicle access control center) can verify the private key root_sk based on the public key root_pk to determine the validity of the first signature information of the first application, thereby confirming whether the information source of the first application is trustworthy. The specific process of the first module verifying the first signature information can be found in [reference needed]. Figure 4 The relevant descriptions in step S404 of the corresponding embodiment will not be repeated here.

[0253] In this embodiment, the first module establishes a trusted chain of trust between the external authorization center and the in-vehicle permission management center by using the pre-set root certificate (including the first public key) of the authorization center. Based on the first public key, the first module can verify whether the first application is trustworthy, thereby constructing a secure and controllable permission management system and realizing application identity authentication and fine-grained permission management.

[0254] Optional, in Figure 7 Based on the corresponding embodiments, the second information is a digital certificate generated by the first application that contains the first signature information; or, the second information is a signature information obtained by signing the first signature information based on the private key of the first application.

[0255] The process of an application sending the second piece of information to the in-vehicle access control center can be referred to... Figure 4 The relevant descriptions in step S403 of the corresponding embodiment will not be repeated. It is understood that the in-vehicle access control center can be responsible for managing the certificate lifecycle of in-vehicle services and applications (including certificate issuance, renewal, revocation, etc.). The second information sent by the first application to the in-vehicle access control center enables the center to authenticate and control access to the first application, thereby improving the security of application access to system data and preventing unauthorized access or tampering with system data.

[0256] Optional, in Figure 7Based on the corresponding embodiments, the first certificate carries the second signature information of the first module. When the identity credential of the first application includes the second public key, the second signature information is the signature information obtained by signing the second public key and the scope of permissions based on the third private key of the first module; or, the second signature information is the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key; wherein, the fourth public key is generated by the first application or generated by the first module for the first application.

[0257] The third private key can be understood as the private key miniCA_sk of the in-vehicle access control center mentioned above. The public key corresponding to the third private key can be the third public key (corresponding to the public key miniCA_pk mentioned above). This third private key and third public key can be used for service verification of applications.

[0258] The second public key corresponds to the application public key app_pk1 mentioned above. This second public key can be generated by the external authorization center for application A, or it can be generated by the application itself; there are no restrictions. The application private key corresponding to this second public key can be app_sk1 mentioned above.

[0259] The fourth public key is the public key of the first application, and the corresponding private key can be the fourth private key. This second or fourth public key can serve as the identity credential of the first application for business interactions with services.

[0260] The second signature information can be understood as the signature information after the in-vehicle access control center uses the private key miniCA_sk to sign the identity credentials and access scope of the first application.

[0261] When the identity credentials of the first application include a second public key, the second signature information can include various implementations. Specifically, the second signature information can be a signature using the private key (i.e., the third private key) of the in-vehicle access control center to sign the original public key (i.e., the second public key) and the permissions, or it can be a signature using the private key of the in-vehicle access control center to sign a fourth public key and the permissions. The fourth public key can be generated by the in-vehicle access control center or the application.

[0262] Understandably, using the private key of the in-vehicle access control center for signing allows services and applications to interact based on the same trust anchor. This enables the construction of a secure and controllable access control system within the vehicle's infotainment system, achieving application authentication and fine-grained access management.

[0263] Optional, in Figure 7Based on the corresponding embodiments, the first certificate carries the second signature information of the first module. When the identity credential of the first application includes the first value, the second signature information is the signature information obtained by signing the fourth public key and the scope of permissions of the first application based on the third private key of the first module; wherein, the fourth public key is generated by the first application or generated by the first module for the first application.

[0264] The explanations of the third private key, the fourth public key, and the second signature information can be found in the relevant descriptions above, and will not be repeated here.

[0265] If the identity credentials of the first application include the first value, the second signature information can be signature information that uses the private key of the in-vehicle access control center (i.e., the third private key) to sign the fourth public key and the permissions. The fourth public key can be generated by the in-vehicle access control center or the application.

[0266] Understandably, using the private key of the in-vehicle access control center for signing allows services and applications to interact based on the same trust anchor. This enables the construction of a secure and controllable access control system within the vehicle's infotainment system, achieving application authentication and fine-grained access management.

[0267] Optional, in Figure 7 Based on the corresponding embodiments, the first service is pre-configured with a third public key of the first module corresponding to the third private key; the first service verifies the first certificate, which may include: the first service verifies the second signature information in the first certificate based on the third public key; if the first certificate is verified successfully, the first service interacts with the first application, which may include: if the second signature information is successfully decrypted based on the third public key, the first service interacts with the first application.

[0268] The third public key can be identified as the public key miniCA_pk mentioned above. The private key corresponding to the third public key is the third private key miniCA_sk. It is understandable that since the second signature information is signed using the third private key, the first service can verify the second signature information based on the third public key.

[0269] In a possible implementation, the first service can verify the first application's first certificate (i.e., the in-vehicle access certificate) based on the root certificate of the in-vehicle access control center (containing the public key miniCA_pk). For details regarding the first service's verification of the first application, please refer to... Figure 4 Regarding the interaction between the first service and the first application, as described in step S405 of the corresponding embodiment, please refer to... Figure 4 The relevant descriptions in step S406 of the corresponding embodiment will not be repeated here.

[0270] Understandably, the first service and the first application can interact based on the same working key. Since other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus enhancing data transmission security. Furthermore, the in-vehicle service enables centralized and standardized access control of system resources, allowing for fine-grained management of application authentication and permissions, thereby improving the security of the vehicle's infotainment system.

[0271] Optional, in Figure 7 Based on the corresponding embodiments, the first module includes a third public key corresponding to the third private key; the first service verifies the first certificate, which may include: the first service sending the first certificate to the first module; the first module verifying the second signature information in the first certificate based on the third public key; and the first service interacting with the first application when the first certificate verification is successful, which may include: the first service interacting with the first application when the second signature information is successfully decrypted based on the third public key.

[0272] In one possible implementation, the first service can send the first application's first certificate to the in-vehicle access control center, which will then verify the certificate. If the verification passes, the first service can interact with the first application, such as granting the first application access to system resources. For details regarding the first service's verification of the first application, please refer to [link to relevant documentation]. Figure 4 Regarding the interaction between the first service and the first application, as described in step S405 of the corresponding embodiment, please refer to... Figure 4 The relevant descriptions in step S406 of the corresponding embodiment will not be repeated here.

[0273] Understandably, the first service and the first application can interact based on the same working key. Since other applications or services cannot obtain this working key, they cannot access the interaction data between the in-vehicle service and application A, thus enhancing data transmission security. Furthermore, the in-vehicle service enables centralized and standardized access control of system resources, allowing for fine-grained management of application authentication and permissions, thereby improving the security of the vehicle's infotainment system.

[0274] Optional, in Figure 7Based on the corresponding embodiments, before the first service and the first application perform business interactions, the process may further include: the first service generating a first working key based on the fifth private key of the first service and the public key of the first application, wherein the public key of the first application is the fourth public key or the second public key; the first application generating a second working key based on the private key of the first application and the fifth public key of the first service, wherein the private key of the first application is the private key corresponding to the fourth public key or the private key corresponding to the second public key, and the fifth public key is the public key corresponding to the fifth private key; the business interactions between the first service and the first application may include: the first service performing business interactions with the first application based on the first working key, and the first application performing business interactions with the first service based on the second working key.

[0275] The first working key corresponds to the working key of the first service. When the first service interacts with the first application, the first service can use the first working key to encrypt or decrypt data.

[0276] The second working key corresponds to the working key of the first application. When the first service and the first application interact, the first application can use the second working key to encrypt or decrypt data. It is understood that the first and second working keys have the same value, but are held by different individuals.

[0277] For details regarding the interaction between the first service and the first application, please refer to... Figure 4 The relevant description in step S406 of the corresponding embodiment, and Figure 6 The relevant descriptions of the corresponding embodiments will not be repeated.

[0278] Understandably, the first service and the first application interact using the same working key, which enhances the confidentiality and integrity of data during cross-process transmission. This way, even if data is intercepted by other applications or services, they cannot decrypt it, thus improving the security of the vehicle's infotainment system.

[0279] The above detailed embodiments have provided a detailed explanation of the purpose, technical solutions, and beneficial effects of the embodiments of this application. It should be understood that the above are merely specific implementations of the embodiments of this application and are not intended to limit the scope of protection of the embodiments of this application. Any modifications, equivalent substitutions, or improvements made based on the technical solutions of the embodiments of this application should be included within the scope of protection of the embodiments of this application. The module names involved in the embodiments of this application can all be defined as other names, as long as they can achieve the function of each module; no specific restrictions are placed on the module names.

[0280] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding access points must be provided for users to choose to authorize or refuse.

[0281] The foregoing mainly describes the technical solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that the method steps described in conjunction with the embodiments of this application can be implemented in hardware or a combination of hardware and software. Whether a function is executed in a hardware-driven or software-driven manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0282] This application provides an electronic device that may include one or more processors and a memory. The memory is coupled to one or more processors. The memory may be used to store programs or instructions. The one or more processors may invoke the programs or instructions to cause the electronic device to execute the technical solutions described above.

[0283] This application provides a chip system. This chip system is applied to an electronic device and may include one or more processors. The one or more processors can be used to invoke programs or instructions to cause the electronic device to execute the technical solutions described above.

[0284] Figure 8 This is a schematic diagram of a chip system provided in an embodiment of this application. The chip system 800 includes one or more processors 801, communication lines 802, communication interfaces 803, and memory 804.

[0285] In some implementations, memory 804 stores elements such as executable modules or data structures, or subsets thereof, or extended sets thereof.

[0286] The methods described in the embodiments of this application can be applied to, or implemented by, processor 801. Processor 801 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above methods can be completed by integrated logic circuits in the hardware of processor 801 or by instructions in software form. Processor 801 may be a general-purpose processor (e.g., a microprocessor or conventional processor), DSP, application-specific integrated circuit, off-the-shelf programmable gate array (FPGA), or other programmable logic device, discrete gate, transistor logic device, or discrete hardware component. Processor 801 can implement or execute the processing-related methods, steps, and logic block diagrams in the embodiments of this application.

[0287] The method described in this application can be implemented using a hardware decoding processor, or by a combination of hardware and software modules within the decoding processor. The software modules can be located in the memory 804, and the processor 801 can read information from the memory 804 and, in conjunction with its hardware, complete the steps of the method described above. The processor 801, the memory 804, and the communication interface 803 can communicate via the communication line 802.

[0288] This application also provides a readable storage medium (also referred to as a computer-readable storage medium). The readable storage medium includes a program or instructions. When the program or instructions are executed on an electronic device, they cause the electronic device to perform the technical solutions described in the above embodiments.

[0289] The methods described in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored or transmitted on a readable medium as one or more programs or instructions. The readable medium can include storage media and communication media, and can also include any medium that can transfer a program from one place to another. The storage medium can be any accessible target medium.

[0290] In possible implementations, the readable medium may include random access memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, optical disc read-only memory, or other optical disc storage. The readable medium may also include disk storage or other disk storage devices, or be directed to any other medium or store the required program in the form of instructions or data structures, and be accessible.

[0291] This application also provides a program product (also referred to as a computer program product). The program product includes a program or instructions. When the program or instructions are run on an electronic device, the electronic device performs the technical solutions described in the above embodiments.

[0292] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions between the various embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0293] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for managing access permissions, characterized in that, The method includes: If the first module of the electronic device passes the verification of the first application of the electronic device, the first module sends the first certificate to the first application; The first service of the electronic device obtains first information from the first application, the first information being used to request business interaction with the first service, and the first information including the first certificate. The first service verifies the first certificate; If the first certificate verification passes, the first service will perform business interactions with the first application.

2. The method as described in claim 1, characterized in that, Before the first module sends the first certificate to the first application after the first module of the electronic device has passed the verification of the first application of the electronic device, the method further includes: The first module obtains the second information of the first application, the second information including the first signature information of the authorization center; The first module verifies the first signature information; When the first module of the electronic device passes the verification of the first application of the electronic device, the first module sends the first certificate to the first application, including: If the first signature information is verified, the first module sends the first certificate to the first application.

3. The method as described in claim 2, characterized in that, The first signature information is obtained by signing the identity credentials and permission scope of the first application based on the first private key of the authorization center.

4. The method as described in claim 3, characterized in that, The identity credentials of the first application include a second public key, which is generated by the authorization center or by the first application. And / or, the identity credentials of the first application include a first value, which is a hash value obtained by hashing the application package of the first application.

5. The method as described in claim 3 or 4, characterized in that, The first module is pre-configured with the first public key of the authorization center corresponding to the first private key; The first module verifies the first signature information, including: The first module verifies the first signature information based on the first public key; If the first signature information verification passes, the first module sends the first certificate to the first application, including: If the first module successfully decrypts the first signature information based on the first public key, the first module sends the first certificate to the first application.

6. The method according to any one of claims 2-5, characterized in that, The second information is a digital certificate generated by the first application that contains the first signature information; or, the second information is a signature obtained by signing the first signature information based on the private key of the first application.

7. The method as described in claim 4, characterized in that, The first certificate carries the second signature information of the first module. When the identity credential of the first application includes the second public key, the second signature information is the signature information obtained by signing the second public key and the scope of permissions based on the third private key of the first module. Alternatively, the second signature information is a signature obtained by signing the fourth public key of the first application and the scope of permissions based on the third private key; wherein the fourth public key is generated by the first application or generated by the first module for the first application.

8. The method as described in claim 4, characterized in that, The first certificate carries the second signature information of the first module. When the identity credential of the first application includes the first value, the second signature information is the signature information obtained by signing the fourth public key of the first application and the scope of permissions based on the third private key of the first module; wherein, the fourth public key is generated by the first application or generated by the first module for the first application.

9. The method as described in claim 7 or 8, characterized in that, The first service is pre-configured with a third public key of the first module corresponding to the third private key; The first service verifies the first certificate, including: The first service verifies the second signature information in the first certificate based on the third public key; When the first certificate verification passes, the first service interacts with the first application for business purposes, including: If the second signature information is successfully decrypted based on the third public key, the first service and the first application will perform business interactions.

10. The method as described in claim 7 or 8, characterized in that, The first module includes the third public key corresponding to the third private key; The first service verifies the first certificate, including: The first service sends the first certificate to the first module; Based on the third public key, the first module verifies the second signature information in the first certificate; When the first certificate verification passes, the first service interacts with the first application for business purposes, including: If the second signature information is successfully decrypted based on the third public key, the first service and the first application will perform business interactions.

11. The method according to any one of claims 7-10, characterized in that, Before the first service interacts with the first application, it also includes: The first service generates a first working key based on the fifth private key of the first service and the public key of the first application, wherein the public key of the first application is the fourth public key or the second public key; The first application generates a second working key based on the private key of the first application and the fifth public key of the first service, wherein the private key of the first application is the private key corresponding to the fourth public key or the private key corresponding to the second public key, and the fifth public key is the public key corresponding to the fifth private key; The first service interacts with the first application in a business manner, including: The first service interacts with the first application based on the first working key, and the first application interacts with the first service based on the second working key.

12. A control device, characterized in that, include: The control unit is used to control the first module of the electronic device to verify the first application of the electronic device, and is also used to control the first module to send the first certificate to the first application; The acquisition unit is used to acquire first information of the first application, the first information being used to request business interaction with the first service, and the first information including the first certificate. The control unit is further configured to control the first service to verify the first certificate, and to control the first service to perform business interactions with the first application if the first certificate verification is successful.

13. The apparatus as claimed in claim 12, characterized in that, The acquisition unit is used to acquire the second information of the first application, the second information including the first signature information of the authorization center; The control unit is used to control the first module to verify the first signature information, and also to control the first module to send the first certificate to the first application if the first signature information is verified successfully.

14. The apparatus as claimed in claim 13, characterized in that, The first signature information is a signature obtained by signing the identity credentials and permission scope of the first application based on the first private key of the authorization center. The first module is pre-set with the first public key of the authorization center corresponding to the first private key. The control unit is used to control the first module to verify the first signature information based on the first public key; The control unit is further configured to control the first module to send the first certificate to the first application when the first module successfully decrypts the first signature information based on the first public key.

15. The apparatus as claimed in claim 14, characterized in that, If the identity credentials of the first application include the second public key... The control unit is used to control the signing of the second public key and the permission scope based on the third private key of the first module to obtain the second signature information of the first module; Alternatively, the control unit is configured to control the signing of the fourth public key of the first application and the permission scope based on the third private key to obtain the second signature information of the first module; The second public key is generated by the authorization center or by the first application, the second signature information is carried in the first certificate, and the fourth public key is generated by the first application or by the first module for the first application.

16. The apparatus as claimed in claim 15, characterized in that, If the identity credentials of the first application include a first value... The control unit is used to control the signature information obtained by signing the fourth public key of the first application and the permission scope based on the third private key of the first module. The second signature information is carried in the first certificate, and the fourth public key is generated by the first application or generated by the first module for the first application. The first value is the hash value obtained by hashing the application package of the first application.

17. The apparatus as claimed in claim 15 or 16, characterized in that, The first service is pre-configured with a third public key of the first module corresponding to the third private key; The control unit is used to control the first service to verify the second signature information in the first certificate based on the third public key; The control unit is further configured to control the first service to perform business interactions with the first application when the second signature information is successfully decrypted based on the third public key.

18. The apparatus as claimed in claim 15 or 16, characterized in that, The first module includes the third public key corresponding to the third private key; The control unit is used to control the first service to send the first certificate to the first module; The control unit is further configured to control the first service to perform business interactions with the first application if the second signature information is successfully decrypted based on the third public key.

19. The apparatus according to any one of claims 15-18, characterized in that, The control unit is used for: The first service is controlled to generate a first working key based on the fifth private key of the first service and the public key of the first application, wherein the public key of the first application is the fourth public key or the second public key; The first application is controlled to generate a second working key based on the private key of the first application and the fifth public key of the first service, wherein the private key of the first application is the private key corresponding to the fourth public key or the private key corresponding to the second public key, and the fifth public key is the public key corresponding to the fifth private key; Control the first service to perform business interactions with the first application based on the first working key, and control the first application to perform business interactions with the first service based on the second working key.

20. A control device, characterized in that, The control device includes a module for performing the method as described in any one of claims 1 to 11.

21. A control device, characterized in that, The control device includes at least one processor and a memory, wherein, The memory is used to store programs or instructions; The at least one processor is used to invoke the program or instructions to cause the control device to perform the method as described in any one of claims 1 to 11.

22. A vehicle, characterized in that, Includes a control device for performing the method as described in any one of claims 1 to 11.

23. A chip, characterized in that, The chip includes at least one processor and an interface circuit, the interface circuit being used to provide information input and / or output to the at least one processor, and the chip being used to perform the method as described in any one of claims 1 to 11.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions that, when executed, cause the method as described in any one of claims 1 to 11 to be performed.

25. A computer program product, characterized in that, Includes a program or instructions that, when run, cause the method as described in any one of claims 1 to 11 to be performed.

Images