Secure chip for sharing data objects and method for sharing data objects

Abstract

The application relates to a secure chip for data object sharing and a data object sharing method. The secure chip has a hardware-isolated trusted execution environment, comprising: a storage module for storing at least one data object and an access control policy corresponding to each data object; a local access control module for receiving an access request of a local device to a target data object, checking the access request according to a local access policy in the trusted execution environment, and performing read / write operations on the target data object after the checking; and a peripheral access control module for receiving an access request of a peripheral entity to the target data object, performing digital envelope unsealing and decryption on the access request in the trusted execution environment, checking the access request according to a peripheral access policy, and performing read / write operations on the target data object after the checking. The chip can complete the access to the data object inside the chip, so that the core business data is always under the hardware-isolated protection in the whole cycle of storage and access.

Description

Technical Field

[0001] This application relates to the field of security chip technology, and in particular to a security chip and a data object sharing method for data object sharing. Background Technology

[0002] With the development of IoT technology, the demand for data confidentiality and integrity protection in inter-device communication is increasing. Security chips, as hardware-level security tools, can generate and store encryption keys and perform encryption operations, and are widely used in IoT terminals to enhance the data security capabilities of devices.

[0003] In existing IoT terminal security architectures, a common approach is for a main control chip and a dedicated security chip to work together. The main control chip executes business logic and runs security processes such as key negotiation and authentication handshakes. When encryption, decryption, or signature operations are required, it calls the cryptographic service interface of the security chip. The security chip executes the encryption, decryption, or signature commands issued by the main control chip and returns the results. The terminal device's business data is stored in the main control chip's non-volatile memory, and the main control chip is responsible for reading, writing, and maintaining the data.

[0004] However, in the aforementioned architecture, security processes such as key negotiation and authentication handshakes are still implemented by software on the main control chip, which poses a risk of being stolen or tampered with by malicious code. Simultaneously, core business data is stored on insecure storage media, making it vulnerable to unauthorized reading or modification through physical probes, firmware vulnerabilities, and other methods. Furthermore, the security chip's function is limited to encryption protection of the communication link, without involvement in the storage, access control, and lifecycle management of data within the terminal device, resulting in a gap between hardware security capabilities and the needs of business data protection. Summary of the Invention

[0005] Therefore, it is necessary to address the aforementioned technical issues by providing a secure chip and data object sharing method that utilizes the security shielding layer protection function of secure chip storage to directly access data objects within the chip, ensuring that core business data remains under hardware isolation protection throughout the entire storage and access cycle.

[0006] Firstly, this application provides a secure chip for data object sharing, featuring a hardware-isolated trusted execution environment, the secure chip comprising:

[0007] A storage module stores at least one data object and access control policies corresponding to each data object, wherein the access control policies include local access policies and external access policies;

[0008] The local access control module is used to receive access requests from local devices to target data objects, verify the access requests according to the local access policy within the trusted execution environment, and perform read and write operations on the target data object after the verification is successful.

[0009] The peripheral access control module is used to receive access requests from the external environment to the target data object, decrypt and unseal the access request within the trusted execution environment, verify the access request according to the peripheral access policy, and perform read and write operations on the target data object after the verification is successful.

[0010] In one embodiment, the local access control module includes:

[0011] The authentication code verification submodule is used to verify the local authentication code carried in the access request using a preset local key under the control of the local access policy.

[0012] In one embodiment, the authentication code verification submodule includes:

[0013] A local key storage unit stores the symmetric key shared with the local device;

[0014] The authentication code comparison unit is used to verify the local authentication code based on the symmetric key using an encryption algorithm.

[0015] In one embodiment, the peripheral access control module includes:

[0016] The digital envelope processing submodule is used to deseal digital envelopes of access requests from peripheral entities, and, under the control of the peripheral access policy, to perform signature verification or authentication code verification on the desealped request original text.

[0017] The response encapsulation submodule is used to encrypt and encapsulate the operation result into a digital envelope after performing read and write operations on the target data object, and then return it to the peripheral entity.

[0018] In one embodiment, the response encapsulation submodule further includes:

[0019] An inner encryption unit is used to perform inner encryption on the operation result using a key negotiated with the peripheral entity;

[0020] The outer encapsulation unit is used to fill the encrypted ciphertext data of the inner layer into the digital envelope of the outer entity.

[0021] In one embodiment, the security chip is provided with a local access interface and a peripheral access interface. The local access interface is used to receive the local access request, and the peripheral access interface is used to receive the peripheral access request.

[0022] In one embodiment, the security chip further includes:

[0023] The national cryptographic algorithm circuit is used to accelerate encryption and decryption algorithms in hardware within the trusted execution environment.

[0024] A random number generation circuit is used to generate random numbers based on physical noise sources within the trusted execution environment to support the digital envelope unsealing and decryption operations of the peripheral access control module.

[0025] Secondly, this application also provides a data object sharing method, applied to the security chip described in any of the above claims, comprising:

[0026] Receive access requests for the target data object;

[0027] If the access request is a local access, then within the trusted execution environment, the access request is verified according to the local access policy associated with the target data object. If the verification passes, read and write operations are performed on the target data object.

[0028] If the access request is a peripheral access request, then within the trusted execution environment, the access request is digitally encapsulated and verified according to the peripheral access policy associated with the target data object. After the verification is successful, read and write operations are performed on the target data object.

[0029] In one embodiment, validating the access request according to the local access policy associated with the target data object includes:

[0030] Extract the local authentication code carried in the access request, and verify the legitimacy of the local authentication code based on a preset local symmetric key.

[0031] In one embodiment, the step of unsealing the access request using a digital envelope and verifying it according to the peripheral access policy associated with the target data object, and then performing read / write operations on the target data object after successful verification, includes:

[0032] Access requests from external entities are decrypted using digital envelopes, and under the control of the external access policy, the decrypted request text is verified by signature or authentication code.

[0033] After performing read and write operations on the target data object, the operation results are encrypted and encapsulated into a digital envelope to be returned to the peripheral entity.

[0034] The aforementioned secure chip and data object sharing method for data object sharing abstract the core business data of the terminal into internal data objects and configure access control policies that separate local and peripheral devices for each object, thereby achieving hardware isolation for different access subjects. By embedding the security processing logic related to data communication from the vulnerable software layer in the existing solution into the hardware isolation area of ​​the secure chip, it ensures that business data is processed within the secure chip, eliminating the risk of software layer attacks and logic tampering, and evolving the secure chip from a passive encryption peripheral to an active data governance node. Attached Figure Description

[0035] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0036] Figure 1 This is a schematic diagram of the architecture of a security chip for sharing data objects in one embodiment;

[0037] Figure 2 This is a block diagram of a secure chip structure for data object sharing in one embodiment;

[0038] Figure 3 This is a structural block diagram of the local access control module in one embodiment;

[0039] Figure 4 This is a structural block diagram of the peripheral access control module in one embodiment;

[0040] Figure 5 This is a flowchart of the steps of a data object sharing method based on a security chip in one embodiment;

[0041] Figure 6 This is a flowchart illustrating the interaction process of a local device reading and updating a data object in one embodiment.

[0042] Figure 7 This is a flowchart illustrating the interaction process of a peripheral device reading and updating a data object in one embodiment. Detailed Implementation

[0043] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0044] The security chip provided in this application embodiment adopts, as follows: Figure 1The diagram illustrates a secure data object storage architecture for IoT terminals. This architecture is suitable for scenarios where terminal devices need to simultaneously support local business object read / write maintenance and shared read / write operations with external entities.

[0045] like Figure 1 As shown, the security chip 12 maintains a local access control module and a peripheral access control module, and stores multiple data objects. The main control unit 11 in the local device 10 interacts with the security chip 12 through a physical interface, using the local access control module to read, write, and maintain the target data objects required for local business processing. The peripheral entity 20 initiates a peripheral shared access request to the security chip 12 through the physical interface, and uses the peripheral access control module to perform read and write operations on the target data objects.

[0046] Local device 10 refers to IoT terminal devices that require data security maintenance and sharing, such as smart gas meters, smart water meters, smart door locks, environmental monitoring nodes, and industrial sensors. Peripheral entity 20 can be external devices or systems that have data sharing needs with the terminal device, including but not limited to: peripheral terminals, multi-collaboration terminals, edge terminals, security gateways, edge gateways, and cloud platforms. The data exchanged between the terminal device and the peripheral entity is business data generated and maintained by local device 10 during operation. Taking a smart gas meter as an example, the business data could include metering information such as meter readings, remaining gas volume, and unit price; device identifiers such as terminal model and firmware version; business account information such as account opening status and overdraft limit; and security log data such as daily gas consumption details and operation records.

[0047] In one exemplary embodiment, such as Figure 2 As shown, a secure chip for sharing data objects is provided, which has a hardware-isolated trusted execution environment and a chip operating system. The secure chip includes a storage module 100, a local access control module 200 and a peripheral access control module 300.

[0048] Storage module 100 stores at least one data object and the access control policy corresponding to each data object. The access control policy includes local access policy and external access policy.

[0049] Among them, data objects are the core business data of local devices, which are abstracted and encapsulated into independent storage units inside the chip. The attributes of each data object include format specifications, storage space size and associated access control policies.

[0050] Access control policy refers to a set of access control rules maintained internally by a security chip, used to determine the permissions and validity of read and write operations on each data object. Access control policy may include authentication code generation and verification methods, whether authentication codes are included, whether signature values ​​are supported, encryption / decryption algorithms, digital envelope structure, signature verification algorithms, the keys used, and certificate agreements for signature and verification, etc.

[0051] The local access control module 200 is used to receive access requests from local devices for target data objects, verify the access requests according to local access policies within a trusted execution environment, and perform read and write operations on the target data object after the verification is successful.

[0052] Receiving access requests from local devices for target data objects refers to the security chip receiving local access requests from the main control unit through a local access interface. A local access request is a request instruction sent by the main control unit to the security chip when it needs to read or write specific data objects within the chip during the execution of business logic.

[0053] When the local access control module receives a local access request, it first looks up the local access policy associated with the target data object in the storage module 100. The local access policy specifies the permission conditions that the local device must meet to access the target object, including but not limited to: the required read and write permission types, the authentication code generation algorithm and verification method, and the local key index used.

[0054] According to this policy, the local access control module verifies the security credentials carried in the local access request. The verification process is completed within the trusted execution environment of the security chip, and the keys involved in the verification are not exposed outside the security chip.

[0055] The peripheral access control module 300 is used to receive access requests from the external environment to the target data object, decrypt and unseal the digital envelope of the access request within the trusted execution environment, and verify it according to the peripheral access policy. After the verification is successful, read and write operations are performed on the target data object.

[0056] In this context, a peripheral access request refers to a remote shared access request initiated by a peripheral entity to the security chip through a peripheral access interface. In existing technologies, peripheral access requests typically reach the local device via network transmission and are then forwarded to the security chip's peripheral access interface by the main control unit or communication module. Because the transmission link of peripheral access requests is exposed to an open network environment, they face higher security threats. Therefore, this embodiment employs digital envelope technology to protect the security of interactions with peripheral devices.

[0057] A digital envelope is a cryptographic encapsulation structure that combines symmetric and asymmetric encryption techniques. After receiving an external access request, the peripheral access control module 300 first uses the private key of the security chip within the trusted execution environment to decrypt the digital envelope, obtaining the session key, and then uses the session key to decrypt the original request text.

[0058] Then, based on the peripheral access policy associated with the target data object, the decrypted request plaintext undergoes signature verification or authentication code verification to confirm the authenticity of the request source and the integrity of the requested data. After all verifications specified by the peripheral access policy pass, the requested read and write operations are executed on the target data object. After the operation is completed, the peripheral access control module 300 also securely encapsulates the operation result and returns it to the peripheral entity, ensuring the security of the response data during the return transmission process.

[0059] In this embodiment, by abstracting core business data into independent data objects within the chip and configuring two separate access control policies for each object, fine-grained hardware isolation for different access subjects is achieved. By embedding the security processing logic related to data communication from the vulnerable software layer in existing solutions into the hardware isolation area of ​​the security chip, it is ensured that business data completes closed-loop processing within the security chip, and plaintext data is never exposed to the device's main control unit, fundamentally eliminating the risk of software layer side-channel attacks and logic tampering. Furthermore, by using a digital envelope authentication method in interactions with external entities, with the envelope encapsulation entirely performed within the security chip, the security of device communication is further guaranteed.

[0060] In one exemplary embodiment, such as Figure 3 As shown, the local access control module 200 includes an authentication code verification submodule 210, which is used to verify the local authentication code carried in the access request using a preset local key under the control of the local access policy.

[0061] Furthermore, the authentication code verification submodule 210 also includes a local key storage unit 211 and an authentication code comparison unit 212. The local key storage unit 211 stores a symmetric key shared with the local device. The authentication code comparison unit 212 is used to verify the local authentication code based on the symmetric key using an encryption algorithm.

[0062] Specifically, the main control unit of the local device needs to calculate the local authentication code corresponding to the target data object according to the preset security policy and initiate a read / write request. Then, the local access control module determines whether the access type is a read or write operation and obtains the local access policy of the target data object. Correspondingly, the local access policy can also include both read and write. Next, the local access control module determines whether the local read / write permissions are satisfied according to the corresponding read or write policy, and then uses the local key to verify the local authentication code in the read / write request. After successful verification, the corresponding read / write operation is executed, and the operation result is returned.

[0063] In this embodiment, by storing the local key required for authentication code verification in a local key storage unit within the security chip, and having the authentication code comparison unit independently verify the local authentication code within a trusted execution environment, both the local access permission verification logic and the key material are confined within a hardware isolation boundary. Compared to the existing technology where the main controller executes the authentication logic at the software layer and the key is exposed in the general-purpose processor's storage space, this embodiment migrates the authentication code verification process from the software environment to the internal hardware of the security chip. Even if an attacker gains control of the main control unit through malicious code, they cannot obtain the local symmetric key and the legitimate authentication code stored within the security chip, thereby effectively blocking unauthorized access paths to data objects.

[0064] In one exemplary embodiment, such as Figure 4 As shown, the peripheral access control module 300 includes a digital envelope processing submodule 310 and a response encapsulation submodule 320.

[0065] The digital envelope processing submodule 310 is used to deseal digital envelopes for access requests from external entities, and under the control of the external access policy, to perform signature verification or authentication code verification on the desealped request original.

[0066] Specifically, the digital envelope processing submodule first uses the private key inside the security chip to perform asymmetric decryption on the encrypted session key in the digital envelope to obtain the plaintext session key; then it uses the session key to perform symmetric decryption on the ciphertext data in the digital envelope to restore the original request text.

[0067] After unblocking, determine whether the access type is read or write operation, obtain the peripheral access policy of the target data object, and determine whether the read and write permissions of the peripheral entity are satisfied under the control of the peripheral access policy. Then, perform signature verification or authentication code verification on the unblocked request original text to confirm the authenticity of the request source and the integrity of the request data.

[0068] The response encapsulation submodule 320 is used to encrypt and encapsulate the operation result into a digital envelope to return to the external entity after performing read and write operations on the target data object.

[0069] Furthermore, the response encapsulation submodule 320 also includes an inner encryption unit 321 and an outer encapsulation unit 322. The inner encryption unit 321 is used to perform inner encryption on the operation result using a key negotiated with the peripheral entity. The outer encapsulation unit 322 is used to fill the encrypted ciphertext data into the digital envelope of the peripheral entity.

[0070] Specifically, the key negotiated with the peripheral entity is a session-level key, shared only between the security chip and the requesting peripheral entity. The inner encryption unit 321 uses a symmetric encryption algorithm to form the inner ciphertext. When the outer encapsulation unit generates the digital envelope, it uses the recipient's public key to perform asymmetric encryption protection on the session key, ultimately forming the outer digital envelope.

[0071] In this embodiment, inner-layer symmetric encryption is performed using an outer protection key negotiated between the terminal and the outer entity. The encrypted data is then encapsulated and filled into the requester's digital envelope. This two-layer message encapsulation effectively ensures the security and integrity of data objects during cross-entity sharing.

[0072] In one exemplary embodiment, the security chip further includes a national cryptographic algorithm circuit 330 and a random number generation circuit 340.

[0073] The national cryptographic algorithm circuit 330 is used to accelerate encryption and decryption algorithms in hardware within a trusted execution environment. Specifically, this circuit provides hardware-level computational support for the SM2 elliptic curve public-key cryptography algorithm, the SM3 cryptographic hash algorithm, and the SM4 block cipher algorithm, enabling efficient completion of cryptographic operations such as asymmetric encryption / decryption, signature verification, data integrity verification, and symmetric encryption / decryption. The national cryptographic algorithm circuit operates independently within the chip, and the key materials involved in its computation remain within the trusted execution environment at all times, without being transmitted through an external bus.

[0074] The random number generation circuit 340 is used to generate random numbers based on physical noise sources within a trusted execution environment to support the digital envelope decryption and unlocking operations of the peripheral access control module. Specifically, the circuit generates unpredictable true random numbers by collecting physical noise sources such as thermal noise and oscillator jitter inside the chip. These numbers are used to generate key security parameters such as session key derivation, challenge value generation, and the construction of temporary keys in digital envelopes.

[0075] The aforementioned national cryptographic algorithm circuit 330 and random number generation circuit 340 work together with the aforementioned storage module 100, local access control module 200 and peripheral access control module 300 to provide hardware support for secure processing in both local access and peripheral sharing scenarios.

[0076] The modules in the aforementioned security chip that shares data objects can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0077] Based on the same inventive concept, this application also provides a data object sharing method based on a security chip. The solution provided by this method is similar to the implementation scheme described in the above embodiments. Therefore, the specific limitations of one or more data object sharing method embodiments based on a security chip provided below can be found in the limitations on the security chip described above, and will not be repeated here.

[0078] In one exemplary embodiment, such as Figure 5 As shown, a data object sharing method based on a security chip is provided, applied to the aforementioned security chip. The method includes:

[0079] Step S401: Receive an access request for the target data object.

[0080] Step S402: If the access request is a local access, then within the trusted execution environment, the access request is verified according to the local access policy associated with the target data object. After the verification is successful, read and write operations are performed on the target data object.

[0081] Step S403: If the access request is a peripheral access, then within the trusted execution environment, the access request is desealed using a digital envelope and verified according to the peripheral access policy associated with the target data object. After the verification is successful, read and write operations are performed on the target data object.

[0082] In one embodiment, such as Figure 6 As shown, the interaction process for a local device to read and update a data object includes the following steps:

[0083] First, the main control unit of the local device calculates the local authentication code corresponding to the object ID according to the preset local access policy and initiates a read / write request. Then, the security chip, according to the local access policy, first verifies the requester's permissions, matches the read / write request against the policy of read or write permissions, and then extracts the local authentication code carried in the access request, verifying the legality of the local authentication code based on the preset local symmetric key. Once the verification is successful, the target data object is accessed, and the read / write result of the target data object is returned to the main control unit.

[0084] In one embodiment, such as Figure 7 As shown, the interaction process for an external entity to read and update a data object includes the following steps:

[0085] First, the peripheral entity constructs a digital envelope based on a preset peripheral access policy and an authentication code or signature value, and initiates a read / write request. Then, the security chip decapsulates the digital envelope of the access request and performs permission verification according to the peripheral access policy associated with the target data object. It matches the read / write permission to the policy and then verifies the signature or authentication code on the decapsulated request text. If the verification passes, the target data object is accessed. After performing read / write operations on the target data object, the operation result is encrypted and encapsulated into a digital envelope and returned to the peripheral entity. Upon receiving the digital envelope, the peripheral entity communicates with the main control unit of the local device to complete the confirmation.

[0086] During communication between the security chip and peripheral entities, the digital envelope is constructed by encrypting business data using a randomly generated session key (symmetric key), and then protecting this session key with the recipient's public key (asymmetric encryption). Together, they form the digital envelope. The recipient internally uses its own private key to decrypt the session key, thereby decrypting the business data. This mechanism ensures that only a security chip holding a legitimate private key can decrypt the requested content, and combines this with signatures or authentication codes to verify message integrity and source authentication.

[0087] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0088] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0089] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0090] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0091] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A secure chip for sharing data objects, featuring a hardware-isolated trusted execution environment, characterized in that, The security chip includes: A storage module stores at least one data object and access control policies corresponding to each data object, wherein the access control policies include local access policies and external access policies; The local access control module is used to receive access requests from local devices to target data objects, verify the access requests according to the local access policy within the trusted execution environment, and perform read and write operations on the target data object after the verification is successful. The peripheral access control module is used to receive access requests from peripheral entities to the target data object, decrypt and unseal the access request within the trusted execution environment, verify it according to the peripheral access policy, and perform read and write operations on the target data object after the verification is successful.

2. The security chip according to claim 1, characterized in that, The local access control module includes: The authentication code verification submodule is used to verify the local authentication code carried in the access request using a preset local key under the control of the local access policy.

3. The security chip according to claim 2, characterized in that, The authentication code verification submodule includes: A local key storage unit stores the symmetric key shared with the local device; The authentication code comparison unit is used to verify the local authentication code based on the symmetric key using an encryption algorithm.

4. The security chip according to claim 1, characterized in that, The peripheral access control module includes: The digital envelope processing submodule is used to deseal digital envelopes of access requests from peripheral entities, and, under the control of the peripheral access policy, to perform signature verification or authentication code verification on the desealped request original text. The response encapsulation submodule is used to encrypt and encapsulate the operation result into a digital envelope after performing read and write operations on the target data object, and then return it to the peripheral entity.

5. The security chip according to claim 4, characterized in that, The response encapsulation submodule also includes: An inner encryption unit is used to perform inner encryption on the operation result using a key negotiated with the peripheral entity; The outer encapsulation unit is used to fill the encrypted ciphertext data of the inner layer into the digital envelope of the outer entity.

6. The security chip according to claim 1, characterized in that, The security chip is equipped with a local access interface and a peripheral access interface. The local access interface is used to receive local access requests, and the peripheral access interface is used to receive peripheral access requests.

7. The security chip according to claim 1, characterized in that, The security chip also includes: The national cryptographic algorithm circuit is used to accelerate encryption and decryption algorithms in hardware within the trusted execution environment. A random number generation circuit is used to generate random numbers based on physical noise sources within the trusted execution environment to support the digital envelope unsealing and decryption operations of the peripheral access control module.

8. A data object sharing method, applied to the security chip according to any one of claims 1 to 7, characterized in that, The method includes: Receive access requests for the target data object; If the access request is a local access, then within the trusted execution environment, the access request is verified according to the local access policy associated with the target data object. If the verification passes, read and write operations are performed on the target data object. If the access request is a peripheral access request, then within the trusted execution environment, the access request is digitally encapsulated and verified according to the peripheral access policy associated with the target data object. After the verification is successful, read and write operations are performed on the target data object.

9. The method according to claim 8, characterized in that, The step of validating the access request according to the local access policy associated with the target data object includes: Extract the local authentication code carried in the access request, and verify the legitimacy of the local authentication code based on a preset local symmetric key.

10. The method according to claim 8, characterized in that, The step of unsealing the access request using a digital envelope and verifying it according to the peripheral access policy associated with the target data object, and then performing read / write operations on the target data object after successful verification, includes: Access requests from external entities are decrypted using digital envelopes, and under the control of the external access policy, the decrypted request text is verified by signature or authentication code. After performing read and write operations on the target data object, the operation results are encrypted and encapsulated into a digital envelope to be returned to the peripheral entity.

Images