A multi-core SoC peripheral permission acquisition method, device, equipment, medium and product

Abstract

The application discloses a multi-core SoC peripheral permission acquisition method, device, equipment, medium and product, relates to the safe technical field, and the method comprises the following steps: generating system public parameters and a master key through a key generation center; determining an identity identifier of a permission request entity; generating a partial private key based on the master key and the identity identifier through the key generation center; and sending the partial private key to the permission request entity; generating a complete key pair based on the partial private key, a preset secret value, the identity identifier and the system public parameters through the permission request entity; signing permission request information using the complete private key through the permission request entity to obtain a target signature; and sending the target signature and a partial public key to a permission arbitration unit; verifying the target signature based on the target signature and the partial public key through the permission arbitration unit to obtain a verification result; if the verification result indicates that the target signature passes the verification, a target peripheral access permission is granted, and the application can guarantee the safe operation of the system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of security, in particular to a multi-core SoC peripheral permission acquisition method, device, equipment, medium and product. BACKGROUND

[0002] With the continuous progress of semiconductor technology, multi-core system-on-chip (SoC) has been widely used in high-performance computing, automotive electronics, industrial control, and smart terminals due to its powerful computing power and integration advantages, and has become a standard hardware platform in these fields. Multi-core SoC can integrate multiple processor cores, rich hardware peripherals, and various functional modules on a single chip, providing solid hardware support for complex and diverse application scenarios.

[0003] In actual applications, to meet the diversified needs of different complex application scenarios, multiple operating systems are usually run on a SoC at the same time, thereby forming a heterogeneous multi-OS environment. However, in the heterogeneous multi-OS environment of multi-core SoC, the hardware peripherals on the SoC become shared resources. These hardware peripherals are diverse, including GPUs, cameras, CAN bus controllers, secure storage units, etc.

[0004] Since these hardware peripherals are shared resources, different operating systems and their running applications may need to access and operate these peripherals. If the peripheral permission management is not proper, security vulnerabilities may occur, allowing malicious programs to obtain access permissions to critical peripherals, posing a serious threat to the safe operation of the system. SUMMARY

[0005] The purpose of the present application is to provide a multi-core SoC peripheral permission acquisition method, device, equipment, medium and product, which can ensure the safe operation of the system.

[0006] To achieve the above purpose, the present application provides the following solutions:

[0007] In a first aspect, the present application provides a multi-core SoC peripheral permission acquisition method applied to a multi-core system-on-chip, wherein the multi-core system-on-chip includes a plurality of permission request entities, and the multi-core SoC peripheral permission acquisition method comprises:

[0008] generating a system public parameter and a master key by a key generation center; wherein the key generation center runs in a high-trust environment of the multi-core system-on-chip;

[0009] determining an identity identifier of the permission request entity; wherein the identity identifier of each permission request entity is unique;

[0010] generating, by the key generation center, a partial private key based on the master key and the identity identifier; and sending the partial private key to the permission requesting entity;

[0011] generating, by the permission requesting entity, a complete key pair based on the partial private key, a preset secret value, the identity identifier, and the system public parameter; wherein the complete key pair comprises the partial private key, a complete private key, a partial public key, and a complete public key;

[0012] signing, by the permission requesting entity, permission request information using the complete private key to obtain a target signature; and sending the target signature and the partial public key to a permission arbitration unit; wherein the permission request information comprises a peripheral device identity of a target peripheral device, an identity identifier of the permission requesting entity, an operation type, and a security parameter; the permission arbitration unit runs in the high-trust environment;

[0013] verifying, by the permission arbitration unit, the target signature based on the target signature and the partial public key to obtain a verification result;

[0014] if the verification result indicates that the target signature passes the verification, granting the target peripheral device access permission.

[0015] Optionally, generating, by the permission requesting entity, a complete key pair based on the partial private key, a preset secret value, the identity identifier, and the system public parameter, specifically comprises:

[0016] generating, by the permission requesting entity, a complete private key based on the partial private key and the preset secret value;

[0017] generating, by the permission requesting entity, a partial public key based on the preset secret value and the system public parameter;

[0018] generating, by the permission requesting entity, a complete public key based on the partial public key and the identity identifier;

[0019] the complete key pair is constituted based on the partial private key, the complete private key, the partial public key, and the complete public key.

[0020] Optionally, signing, by the permission requesting entity, permission request information using the complete private key to obtain a target signature, specifically comprises:

[0021] obtaining a peripheral device identity of a target peripheral device and an operation type of a permission request;

[0022] obtaining a security parameter; wherein the security parameter is a current timestamp or a random number;

[0023] generating permission request information based on the peripheral identity, the identity identifier, the operation type, and the security parameter;

[0024] signing the permission request information using the complete private key to obtain a target signature.

[0025] Optionally, the verifying, by the permission arbitration unit, the target signature based on the target signature and the partial public key to obtain a verification result specifically includes:

[0026] extracting the permission request information from the target signature by the permission arbitration unit;

[0027] extracting the identity identifier from the permission request information;

[0028] performing signature verification on the target signature using the identity identifier, the partial public key, and the system public parameter to obtain a verification result.

[0029] Optionally, if the verification result indicates that the target signature passes the verification, granting the target peripheral access permission specifically includes:

[0030] if the verification result indicates that the target signature passes the verification, determining whether the permission request entity has the right to request the target peripheral to obtain a determination result;

[0031] if the determination result indicates that the permission request entity has the right to request the target peripheral, detecting a current use state of the target peripheral;

[0032] if the current use state indicates that the target peripheral is running normally, granting the target peripheral access permission.

[0033] Optionally, after the target peripheral is granted access permission, the method further includes:

[0034] when the authorization time limit of the target peripheral expires, revoking the access permission granted to the target peripheral;

[0035] or,

[0036] when a permission release request sent by the permission request entity is received, revoking the access permission granted to the target peripheral.

[0037] In a second aspect, the present application provides a multi-core SoC peripheral permission acquisition device applied to a multi-core system on a chip, the multi-core system on a chip comprising a plurality of permission request entities, and comprising:

[0038] The first generating unit is configured to generate system public parameters and a master key by a key generation center; wherein the key generation center runs in a high-trust environment of the multi-core system on chip (SoC).

[0039] The determining unit is configured to determine an identity identifier of the permission requesting entity; wherein the identity identifier of each permission requesting entity is unique.

[0040] The second generating unit is configured to generate a partial private key based on the master key and the identity identifier by the key generation center, and send the partial private key to the permission requesting entity.

[0041] The third generating unit is configured to generate a complete key pair based on the partial private key, a preset secret value, the identity identifier and the system public parameters by the permission requesting entity; wherein the complete key pair comprises the partial private key, a complete private key, a partial public key and a complete public key.

[0042] The signing unit is configured to sign permission request information by the permission requesting entity using the complete private key to obtain a target signature, and send the target signature and the partial public key to a permission arbitration unit; wherein the permission request information comprises a peripheral identity of a target peripheral, an identity identifier of the permission requesting entity, an operation type and a security parameter; and the permission arbitration unit runs in the high-trust environment.

[0043] The verifying unit is configured to verify the target signature based on the target signature and the partial public key by the permission arbitration unit to obtain a verification result.

[0044] The granting unit is configured to grant the target peripheral an access permission if the verification result indicates that the target signature passes the verification.

[0045] In a third aspect, a computer device is provided, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor executes the computer program to implement the steps of the multi-core SoC peripheral permission acquisition method in any of the above embodiments.

[0046] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program is executable on a processor to implement the steps of the multi-core SoC peripheral permission acquisition method in any of the above embodiments.

[0047] In a fifth aspect, a computer program product is provided, which comprises a computer program, and the computer program is executable on a processor to implement the steps of the multi-core SoC peripheral permission acquisition method in any of the above embodiments.

[0048] In a sixth aspect, the present application provides a chip, comprising a processor and a communication interface, the communication interface and the processor being coupled, the processor being configured to run a program or an instruction, and the processor implementing the steps of the multi-core SoC peripheral permission acquisition method according to any one of the above aspects when executing the program or the instruction.

[0049] According to the embodiments provided in the present application, the following technical effects are disclosed.

[0050] The present application provides a multi-core SoC peripheral permission acquisition method, device, equipment, medium and product. By setting a key generation center and a permission arbitration unit in a high-trust environment of a multi-core system on chip, the key generation center is used to generate system public parameters and a master key, and a unique identity identifier and a partial private key are generated for a permission request entity. The permission request entity generates a complete key pair based on this and signs the permission request information. The permission arbitration unit verifies the signature, and only if the verification is passed, the target peripheral access permission is granted. From key generation, identity identification to signature verification, a multi-level security protection mechanism is constructed, which effectively prevents illegal entities from obtaining peripheral access permission, avoids system failure and data leakage risks caused by permission abuse or malicious access, and thus ensures the safe operation of the system. BRIEF DESCRIPTION OF DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0052] Figure 1 An application environment diagram of a multi-core SoC peripheral permission acquisition method according to an embodiment of the present application;

[0053] Figure 2 A flowchart of a multi-core SoC peripheral permission acquisition method according to an embodiment of the present application;

[0054] Figure 3 A functional module diagram of a multi-core SoC peripheral permission acquisition device according to an embodiment of the present application;

[0055] Figure 4 A structural diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0056] With reference to the drawings and embodiments of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts are within the scope of the present application.

[0057] The above purposes, features and advantages of the present application will be more apparent and understandable. The present application will be further described in detail below with reference to the drawings and specific embodiments.

[0058] The multi-core SoC peripheral permission acquisition method provided by the embodiments of the present application can be applied to the application scenario as shown in Figure 1 The multi-core system on chip includes a plurality of permission request entities, i.e., permission request entity 1, permission request entity 2, …, and permission request entity i. The multi-core system on chip also includes a high-trust environment (such as a dedicated security core or a security partition of a Hypervisor), a key generation center (KGC), and a permission arbitration center, which are all running in the high-trust environment. The permission request entity (for example, the permission request entity 1) can perform data transmission with a target peripheral (such as a GPU, a camera, a CAN bus controller, a secure storage unit, etc.). The permission request entity can be an operating system or a specific task in the operating system.

[0059] In an exemplary embodiment, as shown in Figure 2 A multi-core SoC peripheral permission acquisition method is provided, which is executed by a computer device, specifically, by a terminal or a server, or by both a terminal and a server. The method includes the following steps 201 to 207. Specifically,

[0060] Step 201: generating a system public parameter and a master key by a key generation center.

[0061] In the embodiments of the present application, the key generation center runs in a high-trust environment of the multi-core system on chip. The system public parameter params is public to all entities in the system, and the master key msk is kept secret by the KGC.

[0062] Step 202: determining an identity identifier of the permission request entity.

[0063] In the embodiments of the present application, the identity identifier ID of each permission request entity is unique. For example, the Linux system on the permission request entity 0 is identified as IDLinux, and the RTOS system on the permission request entity 1 is identified as IDRTOS.

[0064] Step 203, generating a partial private key by the key generation center based on the master key and the identity identifier, and sending the partial private key to the permission requesting entity.

[0065] In the embodiments of the present application, for any permission requesting entity IDi, the KGC calculates a partial private key Di using the master key msk and the identity identifier IDi of the entity, Di = f(msk, IDi). The partial private key is distributed to the corresponding permission requesting entity through a secure channel.

[0066] Step 204, generating a complete key pair by the permission requesting entity based on the partial private key, a preset secret value, the identity identifier and the system public parameter.

[0067] In the embodiments of the present application, the complete key pair includes the partial private key Di, a complete private key SKi, a partial public key Pi and a complete public key PKi.

[0068] As an optional implementation, the way of generating a complete key pair by the permission requesting entity based on the partial private key, a preset secret value, the identity identifier and the system public parameter in step 204 can include:

[0069] generating a complete private key by the permission requesting entity based on the partial private key and the preset secret value;

[0070] generating a partial public key by the permission requesting entity based on the preset secret value and the system public parameter;

[0071] generating a complete public key by the permission requesting entity based on the partial public key and the identity identifier;

[0072] generating a complete public key by the permission requesting entity based on the partial public key and the identity identifier;

[0073] In the implementation, the generation process of the complete key pair is finely disassembled into the step-by-step generation of the complete private key, the partial public key and the complete public key, and the complete key pair is formed based on the partial private key, the complete private key, the partial public key and the complete public key, so that the generation logic of the key is clear and orderly. The key generation of the permission request entity in combination with the partial private key, the preset secret value, the identifier and the system public parameter ensures the close association of the key generation process with the overall security mechanism of the system, and increases the complexity and security of the key generation by using the preset secret value. Meanwhile, the step-by-step generation of the key facilitates the management and verification of each component of the key, and in the subsequent permission request signature and verification link, the problem can be more accurately located, so that only the legitimate and compliant permission request entity with the correct complete key pair can pass the verification, thereby effectively preventing illegal access and providing a solid guarantee for the safe and stable operation of the multi-core SoC system.

[0074] In the embodiment of the application, the permission request entity i selects a secret value xi by itself.

[0075] The complete private key of the permission request entity is composed of the secret value and the partial private key, that is, SKi=(xi, Di).

[0076] The permission request entity calculates the partial public key Pi=g(xi, params) according to the secret value xi and the system public parameter params.

[0077] The complete public key PKi of the permission request entity is implicitly represented by the identifier IDi and the partial public key Pi, that is, PKi=(Pi, IDi). The public key does not need a certificate to prove the binding relationship with the identifier.

[0078] In step 205, the complete private key of the permission request entity is used to sign the permission request information to obtain a target signature, and the target signature and the partial public key are sent to the permission arbitration unit.

[0079] In the embodiment of the application, the permission request information includes the peripheral identifier of the target peripheral, the identifier of the permission request entity, the operation type and the security parameter; and the permission arbitration unit runs in the high-trust environment.

[0080] As an optional implementation, the way of signing the permission request information by the permission request entity using the complete private key to obtain a target signature in step 205 can include:

[0081] Obtaining the peripheral identifier of the target peripheral and the operation type of the permission request;

[0082] Obtaining the security parameter; wherein the security parameter is a current timestamp or a random number;

[0083] generate permission request information based on the peripheral identity, the identity identifier, the operation type, and the security parameter;

[0084] sign the permission request information using the complete private key to obtain a target signature.

[0085] In this embodiment, the permission request range is accurately defined by obtaining the target peripheral identity and the operation type. The current timestamp or random number is introduced as the security parameter to give the request dynamic uniqueness and effectively resist replay attacks. The permission request information is generated based on multiple elements, and the complete private key is signed to guarantee the legality of the permission request from the dual dimensions of information integrity and source authenticity, thereby laying a solid foundation for the safe and stable operation of the multi-core SoC system.

[0086] In the embodiment, when a permission request entity (such as IDLinux) needs to access a target peripheral (such as PeripheralUART), a permission request information M can be constructed. The information at least includes: the identity identifier of the permission request entity IDLinux, the peripheral identity IDUART, the requested operation type (such as read / write / exclusive), and the security parameter (timestamp or random value).

[0087] The permission request entity uses its complete private key SKLinux to sign the message M to generate a signature σ = Sign(M, SKLinux).

[0088] In step 206, the target signature is verified by the permission arbitration unit based on the target signature and the partial public key to obtain a verification result.

[0089] In the embodiment, the permission arbitration unit can be a Hypervisor, a dedicated management OS, or a security application in TEE.

[0090] As an optional embodiment, the manner in which step 206 verifies the target signature based on the target signature and the partial public key by the permission arbitration unit to obtain a verification result can include:

[0091] extracting the permission request information from the target signature by the permission arbitration unit;

[0092] extracting the identity identifier from the permission request information;

[0093] verifying the target signature using the identity identifier, the partial public key, and the system public parameter to obtain a verification result.

[0094] In this embodiment, the verification process is orderly carried out by the permission arbitration unit, the permission request information is accurately extracted from the target signature first, the clear understanding of the whole request is ensured, the identity identifier is extracted to determine the request subject, and finally the signature verification is carried out in combination with the identity identifier, the partial public key and the system public parameter. This multi-step and multi-element collaborative verification method constructs a rigorous and scientific verification system, which can not only efficiently identify the legality of the permission request, effectively intercept illegal access and prevent malicious attacks from damaging the system, but also can guarantee the rapid passing of the legal request and improve the overall operation efficiency of the system, thereby providing a solid guarantee for the safe and stable operation of the multi-core SoC system.

[0095] In the embodiment of the application, the identity identifier IDLinux of the permission request entity is extracted from the message M.

[0096] The permission arbitration unit verifies the validity of the signature σ by using the identity identifier IDLinux of the permission request entity and the partial public key PLinux (which can be sent with the request or read from a public area) in combination with the system public parameter params. The verification process is Verify(M, σ, PKLinux).

[0097] When the signature verification is passed, it is proved that the request is indeed sent by the legal IDLinux and is not tampered.

[0098] Step 207, if the verification result indicates that the target signature passes the verification, the target peripheral device is granted access permission.

[0099] In the embodiment of the application, the permission arbitration unit grants the permission. The specific actions of authorization can include: configuring the IOMMU (input / output memory management unit) to map the MMIO address space of the target peripheral device to the permission request entity OS; modifying the relevant hardware registers to enable access; or returning a time-limited authorization token (Token) to the permission request entity.

[0100] In addition, the permission arbitration unit further checks whether the IDLinux has the right to request the IDUART and whether the IDUART is currently available according to the system preset access control policy (ACL).

[0101] As an optional embodiment, the way of step 207 of granting the target peripheral device access permission if the verification result indicates that the target signature passes the verification can include:

[0102] If the verification result indicates that the target signature passes the verification, it is judged whether the permission request entity has the right to request the target peripheral device, and a judgment result is obtained.

[0103] If the judgment result indicates that the permission requesting entity has the right to request the target peripheral device, a current use state of the target peripheral device is detected.

[0104] If the current use state indicates that the target peripheral device is in normal operation, access permission of the target peripheral device is granted.

[0105] In this embodiment, on the basis of the target signature being verified, it is further judged whether the permission requesting entity has the right to request the target peripheral device, which is like adding an identity checking checkpoint in front of a security gate, ensuring that only entities with corresponding permissions can enter the subsequent process, effectively preventing unauthorized access. Then, the current use state of the target peripheral device is detected, and access permission is granted only when the peripheral device is in normal operation, avoiding the risk of system instability or data damage caused by peripheral device failure or abnormal state. This mechanism of layer-by-layer screening and strict control not only ensures that system resources are used legally and reasonably, but also improves the overall security and reliability of the system, creating a good environment for stable operation of the multi-core SoC system.

[0106] As an optional embodiment, after step 207, the following steps can also be performed:

[0107] When the authorization time limit of the target peripheral device expires, the access permission granted to the target peripheral device is revoked;

[0108] Or,

[0109] When the release permission request sent by the permission requesting entity is received, the access permission granted to the target peripheral device is revoked.

[0110] In this embodiment, when the authorization time limit of the target peripheral device expires, the access permission is automatically revoked, which is like setting an accurate "hourglass" for permission use, ensuring that the peripheral device will not continue to occupy system resources after the authorization time limit is exceeded, effectively avoiding the situation of permission abuse and long-term invalid occupation of resources, and ensuring the reasonable allocation and efficient use of system resources. When the release permission request sent by the permission requesting entity is received, the permission is revoked in a timely manner, which gives the permission requesting entity the ability to actively manage permissions, enabling it to flexibly adjust access to the peripheral device according to actual business needs, further improving the flexibility and convenience of system use.

[0111] In the embodiment, after the permission requesting entity is authorized, it directly accesses the target peripheral device. When the use is completed, a timeout occurs, or a higher priority request occurs, the permission arbitration unit can actively revoke the permission, and the specific action is the reverse operation of the granted action (such as removing IOMMU mapping).

[0112] Compared with the prior art, the present application has the following remarkable beneficial effects:

[0113] Lightweight and efficient: The complex process of certificate generation, storage, distribution and verification in PKI system is eliminated, significantly reducing the computational burden and storage requirements of the system, which is very suitable for resource-sensitive SoC environment.

[0114] Safe and reliable: The authenticity of the requester's identity and the integrity of the request are guaranteed by cryptography. Since part of the private key is kept by the user, the key escrow problem in traditional IBE (Identity-Based Encryption) is solved, and the security is higher.

[0115] High flexibility: The entire permission application and grant process can be dynamically performed at runtime, supporting on-the-fly resource reallocation, greatly improving hardware resource utilization and system adaptability.

[0116] Architectural decoupling: Separate the permission authentication (guaranteed by cryptography) from the permission decision (determined by policy). The authentication process can be verified in a distributed manner, reducing the performance pressure on the centralized arbitration node and improving the overall robustness of the system.

[0117] In order to make the purpose, technical scheme and advantages of the present application more clear and obvious, the present application is illustrated as follows:

[0118] Dynamic permission granting for CAN bus controller in intelligent cockpit SoC:

[0119] On a typical automotive intelligent cockpit SoC, Android (as an infotainment system) and RTOS (as an instrument panel system) are running, both of which need to dynamically apply for and use the CAN bus controller.

[0120] 1. System environment

[0121] Hardware platform: A multi-core SoC, in which Core0-3 runs the Android system and Core4 runs a QNX RTOS. The SoC contains a CAN bus controller and an IOMMU.

[0122] Software entities:

[0123] Key Generation Center (KGC) and Permission Arbitration Unit (PAU): running on a separate security co-processor built-in in the SoC, which has the highest security level.

[0124] Permission Request Entity 1 (Android): identity ID is ID_Android.

[0125] Permission Request Entity 2 (RTOS): identity ID is ID_RTOS.

[0126] Target peripheral: CAN bus controller, identity ID as ID_CAN.

[0127] Initial state: After system startup, CAN bus controller is exclusively occupied by RTOS by default, and IOMMU has mapped the address space of CAN controller to Core4.

[0128] 2. Implementation steps

[0129] Step 1: Initialization

[0130] 1) System power on, secure co-processor starts first, KGC runs.

[0131] 2) KGC generates system parameters params and master key msk based on the pre-set elliptic curve (such as secp256r1).

[0132] 3) Android and RTOS register their own identity IDs to KGC through secure inter-core communication mechanism during their respective startup processes.

[0133] 4) KGC calculates partial private keys D_Android and D_RTOS for ID_Android and ID_RTOS respectively, and returns them through a secure channel.

[0134] 5) Android and RTOS each generate secret values x_Android and x_RTOS, and combine them into their respective complete key pairs.

[0135] Step 2: Permission application

[0136] 1) During vehicle driving, RTOS continuously communicates with other ECUs of the vehicle through CAN bus.

[0137] 2) At this time, the driver starts a "vehicle diagnosis" application on the Android center screen. The application needs to send specific diagnostic messages (OBD requests) to the CAN bus.

[0138] 3) After receiving the request of the application, the Android system kernel constructs a permission request message M. M = {"requester_id": "ID_Android", "peripheral_id": "ID_CAN", "access_type": "exclusive_write", "duration_sec": 120, "nonce": "0x1a2b3c4d"}

[0139] 4) Android signs the hash of M with its full private key SK Android = (x Android, D Android) to get the signature σ Android.

[0140] 5) Android sends (M, σ Android) and its partial public key P Android to the Permission Arbitration Unit PAU running on the secure co-processor.

[0141] Step 3: Arbitration and Grant

[0142] 1) PAU receives the request.

[0143] 2) PAU verifies the signature σ Android using P Android, ID Android and system parameters params. Verification passes, confirming that the request is legitimate and the content is not tampered.

[0144] 3) PAU queries the internal access control policy table. The policy states that ID Android can temporarily request exclusive write permission for ID CAN when the vehicle state = parked.

[0145] 4) PAU checks the current vehicle state (for example, by reading a certain memory area shared by the RTOS) and confirms that the vehicle is in the parked state. Policy check passes.

[0146] 5) PAU sends a high-priority interrupt to the RTOS, notifying it to "suspend CAN bus usage rights". After completing the current task, the RTOS enters a waiting state and returns an acknowledgement message.

[0147] 6) After receiving the RTOS's confirmation, PAU modifies the IOMMU's page table, unmapping the MMIO address segment of the CAN bus controller from Core4 and mapping it to Core0-3.

[0148] 7) PAU returns a "grant success" message to the Android system.

[0149] Step 4: Access and Revocation

[0150] 1) After receiving the success message, the CAN driver of the Android system can normally access the CAN controller, send diagnostic messages and read responses.

[0151] 2) Two cases of permission revocation:

[0152] · Timeout revocation: After the internal timer of PAU reaches 120 seconds, PAU automatically executes the revocation process.

[0153] • Proactive release: the "vehicle diagnostics" application exits, and the Android system proactively sends a signed request to the PAU to "release permissions".

[0154] The revocation procedure is the inverse of the grant: the PAU first configures the IOMMU to unmap the CAN controller from Android, then remap it to the RTOS, and notifies the RTOS to resume work.

[0155] Through the embodiment, the application successfully realizes the safe, dynamic and on-demand sharing of the key hardware peripherals between a high-security level real-time system and a functional rich non-real-time system, and the whole process does not need to be restarted, is transparent to the user, and greatly improves the flexibility and resource utilization of the system.

[0156] The steps 201 to 207 are implemented, from key generation, identity to signature verification, a multi-level security protection mechanism is constructed, which effectively prevents illegal entities from obtaining peripheral access permissions, avoids system failure and data leakage caused by unauthorized access or malicious access, and thus can ensure the safe operation of the system. In addition, the application can more accurately locate the problem, ensure that only a legitimate and compliant permission request entity can pass the verification by using a correct and complete key pair, thereby effectively preventing illegal access. In addition, the application can ensure the legality of the permission request from the dual dimensions of information integrity and source authenticity, and lay a solid foundation for the safe and stable operation of the multi-core SoC system. In addition, the application can effectively intercept illegal access and prevent malicious attacks from damaging the system, and can also ensure the rapid passing of legal requests and improve the overall operation efficiency of the system. In addition, the application can not only ensure that system resources are used legally and reasonably, but also improve the overall security and reliability of the system, creating a good environment for the stable operation of the multi-core SoC system. In addition, the application can flexibly adjust the access to the peripheral according to actual business needs, further improving the flexibility and convenience of system use.

[0157] Based on the same inventive concept, the embodiment of the application also provides a multi-core SoC peripheral permission acquisition device for implementing the multi-core SoC peripheral permission acquisition method described above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme described in the above method, so the specific limitations in one or more multi-core SoC peripheral permission acquisition device embodiments provided below can be referred to the limitations of the multi-core SoC peripheral permission acquisition method in the foregoing, which will not be repeated here.

[0158] In one exemplary embodiment, as shown in Figure 3 a multi-core SoC peripheral permission acquisition device is provided for a multi-core system on a chip, the multi-core system on a chip comprising a plurality of permission request entities, the multi-core SoC peripheral permission acquisition device comprising:

[0159] The first generating unit 301 is configured to generate system public parameters and a master key by a key generation center; wherein the key generation center runs in a high-trust environment of the multi-core system on chip;

[0160] The determining unit 302 is configured to determine an identity identifier of the permission requesting entity; wherein the identity identifier of each permission requesting entity is unique;

[0161] The second generating unit 303 is configured to generate a partial private key by the key generation center based on the master key and the identity identifier, and send the partial private key to the permission requesting entity;

[0162] The third generating unit 304 is configured to generate a complete key pair by the permission requesting entity based on the partial private key, a preset secret value, the identity identifier and the system public parameters; wherein the complete key pair comprises the partial private key, a complete private key, a partial public key and a complete public key;

[0163] The signing unit 305 is configured to sign permission request information by the permission requesting entity using the complete private key to obtain a target signature, and send the target signature and the partial public key to a permission arbitration unit; wherein the permission request information comprises a peripheral identity of a target peripheral, an identity identifier of the permission requesting entity, an operation type and a security parameter; the permission arbitration unit runs in the high-trust environment;

[0164] The verifying unit 306 is configured to verify the target signature by the permission arbitration unit based on the target signature and the partial public key to obtain a verification result;

[0165] The granting unit 307 is configured to grant the target peripheral an access permission if the verification result indicates that the target signature passes the verification.

[0166] As an optional implementation, the third generating unit 304 generates the complete key pair by the permission requesting entity based on the partial private key, the preset secret value, the identity identifier and the system public parameters in the following manner:

[0167] The permission requesting entity generates the complete private key based on the partial private key and the preset secret value;

[0168] The permission requesting entity generates the partial public key based on the preset secret value and the system public parameters;

[0169] The permission requesting entity generates the complete public key based on the partial public key and the identity identifier;

[0170] The complete key pair is constituted based on the partial private key, the complete private key, the partial public key, and the complete public key.

[0171] In this embodiment, the generation process of the complete key pair is finely divided into the step-by-step generation of the complete private key, the partial public key, and the complete public key, and the complete key pair is constituted based on the partial private key, the complete private key, the partial public key, and the complete public key, so that the generation logic of the key is clear and orderly. The key generation of the authority request entity in combination with the partial private key, the preset secret value, the identity identifier, and the system public parameter not only ensures the close association between the key generation process and the overall security mechanism of the system, but also increases the complexity and security of the key generation by using the preset secret value. At the same time, this step-by-step key generation method facilitates the management and verification of each component of the key, and in the subsequent authority request signature and verification link, the problem can be located more accurately, so that only a legitimate and compliant authority request entity with a correct complete key pair can pass the verification, thereby effectively preventing illegal access and providing a solid guarantee for the safe and stable operation of the multi-core SoC system.

[0172] As an optional embodiment, the signature unit 305 can sign the authority request information by using the complete private key by the authority request entity, and the manner of obtaining the target signature can be specifically as follows:

[0173] Obtaining the peripheral identity of the target peripheral and the operation type of the authority request;

[0174] Obtaining a security parameter; wherein the security parameter is a current timestamp or a random number;

[0175] Generating authority request information based on the peripheral identity, the identity identifier, the operation type, and the security parameter;

[0176] Signing the authority request information by using the complete private key to obtain a target signature.

[0177] In this embodiment, the target peripheral identity and the operation type are obtained to accurately define the authority request range, and the current timestamp or the random number is introduced as the security parameter to give the request dynamic uniqueness and effectively resist replay attacks. The authority request information is generated based on multiple elements, and the complete private key is signed, so that the legality of the authority request is ensured from the dual dimensions of information integrity and source authenticity, thereby laying a solid foundation for the safe and stable operation of the multi-core SoC system.

[0178] As an optional embodiment, the verification unit 306 can verify the target signature based on the target signature and the partial public key by the authority arbitration unit to obtain a verification result, and the manner of obtaining the verification result can be specifically as follows:

[0179] extracting the permission request information from the target signature by the permission arbitration unit;

[0180] extracting the identity identifier from the permission request information;

[0181] performing signature verification on the target signature using the identity identifier, the partial public key, and the system public parameter to obtain a verification result.

[0182] In this implementation, the verification process is orderly carried out by the permission arbitration unit, the permission request information is accurately extracted from the target signature to ensure a clear understanding of the request, the identity identifier is extracted to determine the request subject, and finally signature verification is performed in combination with the identity identifier, the partial public key, and the system public parameter. This multi-step, multi-element collaborative verification method builds a rigorous and scientific verification system, which not only efficiently identifies the legality of the permission request, effectively intercepts illegal access, and prevents malicious attacks from damaging the system, but also ensures the rapid passing of legitimate requests and improves the overall operation efficiency of the system, providing a solid guarantee for the safe and stable operation of the multi-core SoC system.

[0183] As an optional implementation, the granting unit 307 can grant the target peripheral access permission in the following manner if the verification result indicates that the target signature passes the verification:

[0184] If the verification result indicates that the target signature passes the verification, it is determined whether the permission request entity has the right to request the target peripheral to obtain a determination result.

[0185] If the determination result indicates that the permission request entity has the right to request the target peripheral, the current use state of the target peripheral is detected.

[0186] If the current use state indicates that the target peripheral is running normally, the target peripheral is granted access permission.

[0187] In this implementation, based on the target signature passing the verification, it is further determined whether the permission request entity has the right to request the target peripheral. This step is like adding an identity verification checkpoint in front of the security gate, ensuring that only entities with corresponding permissions can enter the subsequent process, effectively preventing unauthorized access. Then, the current use state of the target peripheral is detected, and access permission is granted only when the peripheral is running normally, avoiding the risk of system instability or data damage caused by peripheral failure or abnormal state. This layer-by-layer screening and strict mechanism not only ensures that system resources are used legally and reasonably, but also improves the overall security and reliability of the system, creating a good environment for the stable operation of the multi-core SoC system.

[0188] As an optional implementation, the granting unit 307 is further configured to:

[0189] revoke the access permission granted to the target peripheral device when the authorization time limit of the target peripheral device expires;

[0190] or,

[0191] revoke the access permission granted to the target peripheral device when receiving the release permission request sent by the permission request entity.

[0192] In this implementation, when the authorization time limit of the target peripheral device expires, the access permission is automatically revoked, which sets a precise "hourglass" for the permission use, ensures that the peripheral device does not continue to occupy system resources after the authorization time limit is exceeded, effectively avoids the situation of permission abuse and long-term invalid occupation of resources, and guarantees the reasonable allocation and efficient use of system resources. When receiving the release permission request sent by the permission request entity, the permission is revoked in a timely manner, which gives the permission request entity the ability to actively manage the permission, enabling it to flexibly adjust the access to the peripheral device according to actual business needs, further improving the flexibility and convenience of system use.

[0193] By implementing the above-mentioned implementation, a multi-level security protection mechanism is constructed from key generation, identity identification to signature verification, effectively preventing illegal entities from obtaining peripheral device access permissions, avoiding system failures and data breaches caused by permission abuse or malicious access, and thus ensuring the safe operation of the system. In addition, the present application can more accurately locate the problem, ensuring that only legitimate and compliant permission request entities with correct and complete key pairs can pass the verification, thereby effectively preventing illegal access. In addition, the present application can ensure the legality of the permission request from the dual dimensions of information integrity and source authenticity, laying a solid foundation for the safe and stable operation of the multi-core SoC system. In addition, the present application can effectively intercept illegal access and prevent malicious attacks from damaging the system, and can also ensure the rapid passing of legitimate requests, improving the overall operation efficiency of the system. In addition, the present application can not only guarantee that system resources are used legally and reasonably, but also improve the overall security and reliability of the system, creating a good environment for the stable operation of the multi-core SoC system. In addition, the present application can flexibly adjust the access to the peripheral device according to actual business needs, further improving the flexibility and convenience of system use.

[0194] In an exemplary embodiment, a computer device, which can be a server or a terminal, is provided, and an internal structure diagram thereof can be as shown in Figure 4As shown in the figure. The computer device includes a processor, a memory, an input / output interface (Input / Output, referred to as I / O) and a communication interface. Among them, the processor, the memory and the input / output interface are connected through the system bus, and the communication interface is connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capability. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the computer device is used to store multi-core SoC peripheral permission acquisition data. The input / output interface of the computer device is used to exchange information between the processor and the external device. The communication interface of the computer device is used to communicate with the terminal outside through the network connection. The computer program is executed by the processor to realize a multi-core SoC peripheral permission acquisition method.

[0195] Those skilled in the art can understand that, Figure 4 The skilled in the art can understand that,

[0196] In one exemplary embodiment, a computer device is also provided, including a memory and a processor, the memory stores a computer program, and the processor executes the computer program to realize the steps in each of the above method embodiments.

[0197] In one exemplary embodiment, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by the processor to realize the steps in each of the above method embodiments.

[0198] In one exemplary embodiment, a computer program product is provided, which includes a computer program, and the computer program is executed by the processor to realize the steps in each of the above method embodiments.

[0199] In one exemplary embodiment, a chip is provided, which includes a processor and a communication interface, the communication interface and the processor are coupled, the processor is used to run a program or instructions to realize the steps in each of the above method embodiments and achieve the same technical effects. To avoid repetition, it will not be repeated here.

[0200] It should be understood that the chip mentioned in the embodiments of the present application can also be referred to as a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0201] It should be noted that the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present application are all information and data authorized by the user or authorized by all parties, and the collection, use and processing of related data need to comply with relevant regulations.

[0202] It can be understood by those skilled in the art that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program, and the computer program can be stored in a non-volatile computer readable storage medium. When the computer program is executed, it can include the processes of the above-mentioned embodiments of each method. In the embodiments provided in the present application, any reference to memory, database or other medium can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (Read-Only Memory, ROM), magnetic tape, floppy disk, flash memory, optical storage, high-density embedded non-volatile memory, resistive memory (ReRAM), magnetic variable memory (Magnetoresistive Random Access Memory, MRAM), ferroelectric memory (Ferroelectric Random Access Memory, FRAM), phase change memory (Phase Change Memory, PCM), graphene memory, etc. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory, etc. As an illustration but not limitation, RAM can be in various forms, such as static random access memory (Static Random Access Memory, SRAM) or dynamic random access memory (Dynamic Random Access Memory, DRAM), etc.

[0203] The database involved in the embodiments provided in the present application can include at least one of a relational database and a non-relational database. The non-relational database can include a distributed database based on a block chain, etc., without being limited thereto. The processor involved in the embodiments provided in the present application can be a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., without being limited thereto.

[0204] The technical features of the above embodiments can be combined arbitrarily. In order to make the description simple, not all possible combinations of the technical features in the above embodiments are described, but as long as the combination of the technical features does not exist contradictory, it should be considered as the scope of the present application.

[0205] The principles and implementations of the present application are described in detail with specific examples in this paper, and the above examples are only used to help understand the method of the present application and its core idea; at the same time, for those skilled in the art, according to the idea of the present application, the specific implementation and application range will be changed. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A method for obtaining peripheral permissions for a multi-core SoC, applied to a multi-core on-chip system, wherein the multi-core on-chip system includes multiple permission request entities, characterized in that, The method for obtaining permissions for multi-core SoC peripherals includes: The system generates public parameters and a master key through a key generation center; wherein, the key generation center operates in a highly trusted environment of the multi-core on-chip system; Determine the identity identifier of each permission request entity; wherein, the identity identifier of each permission request entity is unique; The key generation center generates a partial private key based on the master key and the identity identifier; and sends the partial private key to the permission request entity. The permission request entity generates a complete key pair based on the partial private key, the preset secret value, the identity identifier, and the system public parameters; wherein, the complete key pair includes the partial private key, the complete private key, the partial public key, and the complete public key; The permission request entity signs the permission request information using the complete private key to obtain the target signature; and sends the target signature and the partial public key to the permission arbitration unit; wherein, the permission request information includes the peripheral identity of the target peripheral, the identity identifier of the permission request entity, the operation type, and security parameters; the permission arbitration unit operates in the high-trust environment; The authentication unit verifies the target signature based on the target signature and the partial public key to obtain a verification result. If the verification result indicates that the target signature has passed verification, then the target peripheral device is granted access permissions. Specifically, the step of generating a complete key pair through the permission request entity based on the partial private key, the preset secret value, the identity identifier, and the system public parameters includes: The permission request entity generates a complete private key based on the partial private key and a preset secret value; The permission request entity generates a partial public key based on the preset secret value and the system's public parameters; The permission request entity generates a complete public key based on the partial public key and the identity identifier; A complete key pair is formed based on the partial private key, the complete private key, the partial public key, and the complete public key.

2. The method for obtaining peripheral permissions for a multi-core SoC according to claim 1, characterized in that, The step of signing the permission request information using the complete private key by the permission request entity to obtain the target signature specifically includes: The operation type for obtaining the peripheral device's identity and permission request information; Obtain security parameters; wherein, the security parameters are the current timestamp or a random number; Based on the peripheral device identity identifier, the identity identifier, the operation type, and the security parameters, generate permission request information; The complete private key is used to sign the permission request information to obtain the target signature.

3. The method for obtaining peripheral permissions for a multi-core SoC according to claim 2, characterized in that, The step of verifying the target signature through the authorization arbitration unit based on the target signature and the partial public key to obtain a verification result specifically includes: The permission request information is extracted from the target signature by the permission arbitration unit. Extract the identity identifier from the permission request information; The target signature is verified using the identity identifier, the partial public key, and the system's public parameters to obtain a verification result.

4. The method for obtaining peripheral permissions for a multi-core SoC according to claim 3, characterized in that, If the verification result indicates that the target signature has passed verification, then granting access permissions to the target peripheral device specifically includes: If the verification result indicates that the target signature has passed verification, then it is determined whether the permission requesting entity has the right to request the target peripheral device, and a determination result is obtained; If the determination result indicates that the permission requesting entity has the right to request the target peripheral, then the current usage status of the target peripheral is detected; If the current usage status indicates that the target peripheral is operating normally, then the target peripheral is granted access permissions.

5. The method for obtaining peripheral permissions for a multi-core SoC according to claim 1, characterized in that, After granting access to the target peripheral device, the method further includes: When the authorization period for the target peripheral expires, the access rights granted to the target peripheral shall be revoked; or, When a release permission request is received from the permission request entity, the access permissions granted to the target peripheral are revoked.

6. A multi-core SoC peripheral permission acquisition device, applied to a multi-core on-chip system, wherein the multi-core on-chip system includes multiple permission request entities, characterized in that, The multi-core SoC peripheral permission acquisition device includes: The first generation unit is used to generate system public parameters and master keys through the key generation center; wherein, the key generation center operates in the high-trust environment of the multi-core on-chip system; A determining unit is used to determine the identity identifier of the permission request entity; wherein, the identity identifier of each permission request entity is unique; The second generation unit is used to generate a partial private key based on the master key and the identity identifier through the key generation center; and send the partial private key to the permission request entity. The third generation unit is used to generate a complete key pair by the permission request entity based on the partial private key, the preset secret value, the identity identifier, and the system public parameters; wherein the complete key pair includes the partial private key, the complete private key, the partial public key, and the complete public key; The signature unit is used to sign the permission request information using the complete private key by the permission request entity to obtain the target signature; and to send the target signature and the partial public key to the permission arbitration unit; wherein, the permission request information includes the peripheral identity identifier of the target peripheral device, the identity identifier of the permission request entity, the operation type, and security parameters; the permission arbitration unit operates in the high-trust environment; The verification unit is used to verify the target signature based on the target signature and the partial public key through the authorization arbitration unit, and obtain the verification result; An granting unit is configured to grant access permissions to the target peripheral device if the verification result indicates that the target signature has passed verification. Specifically, the third generation unit generates a complete key pair based on the partial private key, the preset secret value, the identity identifier, and the system public parameters through the permission request entity in the following manner: The permission request entity generates a complete private key based on the partial private key and a preset secret value; The permission request entity generates a partial public key based on the preset secret value and the system's public parameters; The permission request entity generates a complete public key based on the partial public key and the identity identifier; A complete key pair is formed based on the partial private key, the complete private key, the partial public key, and the complete public key.

7. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the steps of the multi-core SoC peripheral access acquisition method according to any one of claims 1-5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-core SoC peripheral access acquisition method as described in any one of claims 1-5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-core SoC peripheral access acquisition method as described in any one of claims 1-5.

Images