A data decentralized trust exchange control method on an enterprise supply chain

Abstract

The application discloses a kind of data decentralized trusted exchange control methods on enterprise supply chain, it is related to supply chain data exchange management technical field, establishes decentralized supply chain data sharing architecture, and chain master enterprise is deployed main server, each node enterprise submits registration information to main server, each participant enterprise signs electronic protocol, and main server issues digital identity certificate for each node, and establishes node trust list, and establishes the coding identification system corresponding to data resource;The application adopts decentralized storage architecture, and the original data remains in each node local, while clearly defining data ownership, to avoid the security risks of centralized storage;Through unified digital identity certificate and identity verification process, node identity management is standardized, and the legality of data request is ensured;Based on dynamic access key and data use contract, dynamic adjustment of data authorization and use restriction control are realized, to meet the data sharing needs in different scenarios.

Description

Technical Field

[0001] This invention relates to the field of supply chain data exchange management technology, and in particular to a decentralized and trusted data exchange control method in an enterprise supply chain. Background Technology

[0002] As supply chain collaboration becomes increasingly complex, companies need to share data to ensure efficient operation in areas such as demand forecasting, inventory allocation, and logistics tracking. Data has become a core element of supply chain collaboration. However, existing supply chain data sharing models have significant shortcomings: Traditional models often employ a centralized architecture, requiring each node enterprise to upload data to a unified server. This not only leads to unclear data ownership but also makes centralized storage nodes a prime target for cyberattacks, easily causing large-scale data leaks or losses. The lack of unified standards for node enterprise identity management and the non-standardized identity verification process for data requesters make it difficult to effectively identify illegal requests and increase the risk of unauthorized access. Thirdly, data authorization mechanisms are mostly static authorizations, which cannot dynamically adjust access permissions according to usage scenarios, usage periods, etc., and the data usage process lacks effective tracking methods, making it difficult for data providers to grasp the time, purpose, and frequency of data access. Furthermore, the existing data encryption key management lacks flexibility, key expiration control is lagging, and there are no constraints on the security environment for data use. This results in data still facing security risks of misuse or leakage during the decryption and use phase, which seriously restricts the depth and breadth of supply chain data sharing. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention provides a decentralized and trusted data exchange control method for enterprise supply chains. The technical solution adopted is as follows: A method for decentralized and trusted data exchange control in an enterprise supply chain includes the following steps: Step 1: Establish a decentralized supply chain data sharing system architecture, with the chain leader enterprise deploying the main server and each participating enterprise deploying local servers and front-end gateways as nodes; Step 2: Each node enterprise submits registration information to the main server, each participating enterprise signs an electronic agreement, the main server issues digital identity certificates to each node, establishes a node trust list, and establishes a coding and identification system corresponding to data resources; Step 3: The data requester initiates a data request to the master server. The data request includes the identifier code, usage scenario, and usage period of the required data. Step 4: The main server verifies the identity of the data requester and whether the request is within the scope of the registered data sharing scenario; Step 5: The master server sends an authorization request to the data provider. The provider decides whether to authorize based on its own policy and sets dynamic access keys and usage restrictions. Step 6: After authorization is granted, the main server issues a temporary access token and encryption key to the data requester. Step 7: The data requester directly accesses the provider's front-end data gateway with the access token to obtain the encrypted data block. The data provider uses a dynamic key to encrypt the data, and the key is transmitted to the data requester through a secure channel. Step 8: The data requester uses the key to decrypt the data and locally converts the identifier encoding into an internally understandable data format through a semantic mapping table.

[0004] Optionally, in step 1, the specific method for constructing the decentralized supply chain data sharing architecture is as follows: Establish a chain leader enterprise in the supply chain. The chain leader enterprise deploys and maintains a master server as the coordination and registration center for supply chain data sharing. Each participating enterprise acts as a node, deploying a local data server and a front-end data exchange gateway to provide a controllable data access interface to the outside world.

[0005] Optionally, the decentralized supply chain data sharing architecture adopts the principle of decentralized storage, with the original data kept locally on each node and remotely accessed only through an authorization mechanism, and not centrally stored on the main server.

[0006] Optionally, in step 2, the registration information of the node enterprise includes the enterprise identity and the data resource sharing directory, which includes the data type and the scope of data sharing.

[0007] Optionally, all data requests, authorizations, and access records are left on the main server; The data provider has the authority to query the access records of shared data. The access records include the visitor, access time, and access purpose.

[0008] Optionally, in step 3, the identifier encoding adopts a combination structure of scenario code, enterprise code, data type, and data item ID, and each node can customize the mapping relationship between local encoding and identifier encoding.

[0009] Optionally, step 5, setting the dynamic access key and usage restrictions, includes the following sub-steps: Step 5-1: The main server responds to the data provider's authorization for the data request and generates a structured data usage contract. The data usage contract defines at least one of the following: the scope of data use, timeliness, number of uses, and output restrictions. Step 5-2: Generate a data encryption key for encrypting the target data, and encapsulate the data encryption key and the data usage contract together to form a key contract package; Step 5-3: Encrypt the key contract package using the contract encryption key, and encapsulate the contract encryption key using the public key of the data requester. Step 5-4: Send the encapsulated contract encryption key, data resource identifier, and data usage contract digest as authorization credentials to the data requester.

[0010] Optionally, in step 7, the data requester decrypts the private key in a local secure environment to obtain the contract encryption key, and then decrypts the key contract package to extract the data encryption key and the data usage contract. The data provider is allowed to decrypt the acquired data using the data encryption key only when all terms pass the verification, and the data encryption key is invalidated after the contract terms are satisfied.

[0011] Optionally, the steps to invalidate the data encryption key include: after reaching the number of uses or time specified in the contract, the local security agent automatically removes the corresponding data encryption key from memory and uploads the final state hash value of this session to the main server for evidence storage.

[0012] Optionally, the data usage contract may also include execution environment requirements, which specify the minimum security level required for decryption and data usage; the local security environment must provide proof of the environment and grant decryption access after verification.

[0013] In summary, the present invention has at least one of the following beneficial technical effects: This invention provides a decentralized and trusted data exchange control method for enterprise supply chains. It adopts a decentralized storage architecture, with raw data stored locally on each node. This clarifies data ownership while avoiding the security risks of centralized storage. By unifying digital identity certificates and identity verification processes, it standardizes node identity management and ensures the legitimacy of data requests. Based on dynamic access keys and data usage contracts, dynamic adjustment of data authorization and control of usage restrictions are realized to meet the data sharing needs in different scenarios; the entire process of data request, authorization, and access is traceable, and combined with state hash notarization, the data usage process is traceable, ensuring the data provider's right to know; By introducing a local security environment verification and automatic key expiration mechanism, the security of data usage is improved, and data abuse and leakage are effectively prevented. Each node can customize the encoding mapping relationship, balancing the uniformity of data sharing with the autonomy of node data format, thereby improving the adaptability of the solution. Attached Figure Description

[0014] Figure 1 This is a flowchart illustrating a decentralized and trusted data exchange control method for enterprise supply chains according to the present invention. Detailed Implementation

[0015] The present invention will be further described in detail below with reference to the accompanying drawings.

[0016] This invention discloses a method for decentralized and trusted data exchange control in an enterprise supply chain.

[0017] Reference Figure 1 Example 1: A method for decentralized and trusted data exchange control in an enterprise supply chain, comprising the following steps: Step 1: Establish a decentralized supply chain data sharing system architecture, with the chain leader enterprise deploying the main server and each participating enterprise deploying local servers and front-end gateways as nodes; Step 2: Each node enterprise submits registration information to the main server, each participating enterprise signs an electronic agreement, the main server issues digital identity certificates to each node, establishes a node trust list, and establishes a coding and identification system corresponding to data resources; Step 3: The data requester initiates a data request to the master server. The data request includes the identifier code, usage scenario, and usage period of the required data. Step 4: The main server verifies the identity of the data requester and whether the request is within the scope of the registered data sharing scenario; Step 5: The master server sends an authorization request to the data provider. The provider decides whether to authorize based on its own policy and sets dynamic access keys and usage restrictions. Step 6: After authorization is granted, the main server issues a temporary access token and encryption key to the data requester. Step 7: The data requester directly accesses the provider's front-end data gateway with the access token to obtain the encrypted data block. The data provider uses a dynamic key to encrypt the data, and the key is transmitted to the data requester through a secure channel. Step 8: The data requester uses the key to decrypt the data and locally converts the identifier encoding into an internally understandable data format through a semantic mapping table.

[0018] Example 2, in step 1, the specific method for constructing the decentralized supply chain data sharing system architecture is as follows: Establish a chain leader enterprise in the supply chain. The chain leader enterprise deploys and maintains a master server as the coordination and registration center for supply chain data sharing. Each participating enterprise acts as a node, deploying a local data server and a front-end data exchange gateway to provide a controllable data access interface to the outside world.

[0019] Example 3: The decentralized supply chain data sharing system architecture adopts the principle of decentralized storage. The original data is kept locally on each node and can only be accessed remotely through an authorization mechanism. It is not centrally stored on the main server.

[0020] By adopting the above technical solution, the master server is only responsible for coordinating and managing node registration, without centrally storing any original data. Each node's local server independently stores its own original data, and the front-end gateway serves as the sole channel for nodes to interact with the outside world, ensuring the core logic of data immobility and authorized access is implemented. This architecture avoids the inherent risks of ambiguous data ownership and vulnerability to attacks inherent in centralized storage models. Furthermore, by enabling nodes to autonomously manage their local data, it ensures that data ownership and control firmly belong to the data provider. Simultaneously, the front-end gateway establishes a controllable entry point for data access, laying a solid foundation for subsequent access control.

[0021] Each node enterprise submits registration materials to the main server, covering key information such as enterprise identity and data attribute descriptions. Based on the review results, the main server issues a unique digital identity certificate to each node and simultaneously establishes a node trust list. The digital identity certificate serves as the core digital credential for nodes to participate in data exchange, enabling unique identification and traceable verification of each node's identity. The trust list provides a core reference standard for subsequent data request verification, blocking unregistered nodes and nodes with questionable identities from participating in data exchange at the source. This effectively addresses the pain points of chaotic node identity management and difficulty in accurately identifying illegal requests in the traditional model.

[0022] When a data requester initiates a request, it must simultaneously submit the target data identifier code, the data usage scenario, and the usage period. The target data identifier code accurately identifies the required data, the usage scenario clarifies the boundaries of the data's purpose, and the usage period limits the timeliness of data use. These three types of information together provide the core basis for subsequent verification and authorization. The main server first verifies the requester's digital identity, accurately matching it with the trust list, and then checks whether the requested scenario falls within the scope of the requester's registered sharing scenarios. This dual verification process strictly controls the legality of the request. After successful verification, the main server forwards the request to the data provider. The provider, based on its own data sharing strategy and considering factors such as data sensitivity level and its cooperative relationship with the requester, independently decides whether to authorize the request, simultaneously setting dynamic access keys and usage restrictions, including access frequency thresholds and usage constraints, enabling the data provider to have full-process control over its own data.

[0023] After authorization, the main server issues a temporary access token and encryption key to the requester. The temporary access token serves as a temporary pass for the requester to access the data provider's front-end gateway, and is only valid within the authorization period, thus preventing long-term abuse of the token. The encryption key is used for subsequent data decryption operations and is transmitted through a secure channel throughout the process, strictly preventing key leakage during transmission. When the data requester directly connects to the provider's front-end gateway using the temporary access token, the provider encrypts the original data using a previously set dynamic key to generate encrypted data blocks. This ensures that even if the data is illegally intercepted during cross-node transmission, it cannot be directly deciphered to extract valid information, achieving closed-loop security protection across the entire process of transmission, encryption, and key management.

[0024] The data requester decrypts the encrypted data block using the acquired encryption key in its local environment, eliminating the risk of data leakage that may arise from decryption in a third-party environment. Addressing the issue of differing local data encoding across enterprise nodes, a pre-defined semantic mapping table is used to convert the unified identifier encoding used during the request phase into a data format recognizable within each node. This ensures encoding consistency during data sharing, facilitating cross-node data identification, while preserving the autonomy of each node's local data format. This effectively resolves the compatibility challenge between the unified identifier and local data formats, ensuring that the requester can directly use the acquired data.

[0025] In Example 4, in step 2, the registration information of the node enterprise includes the enterprise identity and the data resource sharing directory. The data resource sharing directory includes the data type and the scope of data sharing.

[0026] Example 5: All data requests, authorizations, and access records are left on the main server; The data provider has the authority to query the access records of shared data. The access records include the visitor, access time, and access purpose.

[0027] By adopting the above technical solution, each node independently stores its own raw data through a local server. The front-end gateway serves as the sole channel for external data interaction, ensuring that the data remains unchanged and that access is authorized. This architecture avoids the inherent risks of ambiguous data ownership and vulnerability to attacks inherent in centralized storage models. Furthermore, the node's autonomous management of its local data guarantees that data ownership and control firmly belong to the data provider. The controllable data access entry point established by the front-end gateway further solidifies the architectural foundation for subsequent access control.

[0028] Each node enterprise submits registration materials to the main server, including necessary information such as enterprise identity and data attribute descriptions. Based on the review results, the main server issues a unique digital identity certificate to each node and simultaneously establishes a node trust list. The digital identity certificate serves as the core digital credential for nodes participating in data exchange, enabling unique identification and traceable verification of each node's identity. The trust list provides a core reference for subsequent data request verification, blocking unregistered nodes and nodes with questionable identities from participating in data exchange at the source, effectively solving the problems of chaotic node identity management and difficulty in accurately identifying illegal requests in the traditional model.

[0029] When a data requester initiates a request, it must simultaneously submit the target data identifier code, usage scenario, and usage period. The identifier code accurately locates the required data, the usage scenario clarifies the boundaries of its purpose, and the usage period limits the validity period. These three types of information together provide the core basis for subsequent verification and authorization. The main server first verifies the requester's digital identity and performs a precise match with the trust list. Then, it checks whether the requested scenario falls within the scope of the shared scenarios that the requester has registered. This dual verification strictly controls the legality of the request.

[0030] Once the verification is successful, the main server will forward the request to the data provider. The provider, in conjunction with its own data sharing strategy, will make an independent decision on whether to authorize the request, taking into account the data sensitivity level and the cooperative relationship with the requester. At the same time, dynamic access keys and usage restrictions will be set, including access frequency thresholds and usage constraints, so that the data provider can have full control over its own data throughout the entire process.

[0031] After authorization, the main server issues a temporary access token and an encryption key to the requester. The temporary access token serves as the requester's pass to the data provider's front-end gateway and is only valid within the authorization period, preventing long-term misuse of the token. The encryption key is used for subsequent data decryption operations and is transmitted through a secure channel throughout the process, strictly preventing key leakage during transmission. When the data requester directly connects to the provider's front-end gateway using the temporary access token, the provider encrypts the original data using a preset dynamic key to generate encrypted data blocks. This ensures that even if data is illegally intercepted during cross-node transmission, it cannot be directly parsed for valid information, thus constructing a closed-loop security system encompassing transmission, encryption, and key management.

[0032] The data requester uses the acquired encryption key to decrypt the encrypted data block in its local environment, eliminating the risk of leakage that may occur due to decryption in a third-party environment. Addressing the differences in local data encoding across nodes, a pre-defined local semantic mapping table is used to convert the unified identifier encoding used during the request phase into a format recognizable within each node.

[0033] It ensures the uniformity of encoding during data sharing, facilitating cross-node data identification, while preserving the autonomy of each node's local data format. This effectively solves the compatibility problem between the unified identifier and the local data format, ensuring that the requesting party can directly use the data after obtaining it.

[0034] In Example 6, in step 3, the identification code adopts a combination structure of scenario code, enterprise code, data type, and data item ID. Each node can customize the mapping relationship between local code and identification code.

[0035] By adopting the above technical solution, the various coding segments in the combined structure have clear functions and together constitute a globally unique and semantically clear data identity identifier, providing accurate support for cross-node data location and verification. The scenario code defines the specific shared scenario of data association, covering types such as inventory collaboration, logistics tracking, and order matching. It can directly correspond to the usage scenario in the data request. When the main server verifies the request, it can quickly verify the consistency between the request scenario and the scenario to which the data belongs through the scenario code, preventing data from flowing in unauthorized scenarios.

[0036] The enterprise code uniquely identifies the enterprise to which the data belongs. Each participating enterprise in the supply chain is assigned a unique enterprise code. This code segment can be used to directly locate the data provider, providing a clear direction for the main server to forward data requests and for the requester to access the provider's front-end gateway, thus reducing location errors in data flow.

[0037] Data types distinguish data category attributes, including inventory data, order data, and logistics timeliness data. These are linked to the data types in the node registration information. The main server can quickly filter data categories that meet the request requirements using this encoding segment, improving data matching efficiency. Data item IDs identify the smallest data unit under a specific data type, such as the inventory quantity of a SKU or the order number, ensuring precise data location down to the specific information item. This avoids confusion caused by coarse encoding granularity and prevents situations where only the data category can be located without pinpointing the specific information.

[0038] The mapping relationship between custom local codes and identifier codes at each node essentially builds a bridge for adaptation between a globally unified standard and local operating habits. Over long-term operations, different node enterprises have developed local coding systems tailored to their own business processes. Some enterprises use KC-2025-001 to identify a specific SKU's inventory data, while others use Stock-2025-001 to identify similar data. Forcing a unified local coding system would require restructuring the internal data management system, which would not only be costly but could also disrupt the normal operation of existing businesses.

[0039] Nodes are allowed to establish semantic mapping tables locally, mapping the globally combined identifier encoding to their own local encoding. When interacting with external data, nodes can convert their local encoding to a globally unified identifier encoding based on the mapping table, ensuring consistency in cross-node communication. When receiving external data, the global identifier encoding is converted back to an internally recognizable local encoding through the mapping table, directly connecting to their own business systems. This model of unified external identification and autonomous internal encoding does not require changes to the existing encoding system of nodes, reducing the difficulty of implementation, while ensuring smooth cross-node data interaction, achieving a balance between uniformity and autonomy, and laying the foundation for efficient use of acquired data.

[0040] The data requester decrypts the encrypted data block using the acquired encryption key in its local environment, eliminating the risk of leakage that may occur due to decryption in a third-party environment. Based on the aforementioned local semantic mapping table, the conversion and adaptation between the global identifier encoding and the node's internal format are completed. This ensures encoding consistency during data sharing to facilitate cross-node identification while preserving the autonomy of each node's local data format. This effectively resolves the challenge of adapting a unified identifier to a local data format, ensuring that the requester can directly use the data after obtaining it.

[0041] In Example 7, step 5, setting the dynamic access key and usage restrictions includes the following sub-steps: Step 5-1: The main server responds to the data provider's authorization for the data request and generates a structured data usage contract. The data usage contract defines at least one of the following: the scope of data use, timeliness, number of uses, and output restrictions. Step 5-2: Generate a data encryption key for encrypting the target data, and encapsulate the data encryption key and the data usage contract together to form a key contract package; Step 5-3: Encrypt the key contract package using the contract encryption key, and encapsulate the contract encryption key using the public key of the data requester. Step 5-4: Send the encapsulated contract encryption key, data resource identifier, and data usage contract digest as authorization credentials to the data requester.

[0042] By adopting the above technical solution, the core value of generating the structured data usage contract in step 5-1 lies in building a rule framework that can be implemented and enforced for data usage. Traditional data authorization is often vague, only generally allowing data viewing without clearly defining the scope of use, time limit, frequency of use, and output specifications.

[0043] Step 5-2: The data encryption key is the core element for decrypting the target data. If the key is transmitted separately, it is easy for it to be illegally obtained and abused without regard to authorization rules, such as illegally decrypting data beyond the authorized number of times or abusing data beyond the authorized scope. By encapsulating the key and the contract into a unified package, it can be ensured that the data requester must simultaneously obtain and clearly understand the corresponding usage rules when obtaining the key, thus avoiding the problem of rules being ignored from the source.

[0044] Step 5-3: The first layer of encryption encrypts the key contract package using the contract encryption key, directly protecting the security of core information. Even if the package is illegally intercepted, it cannot be deciphered without the corresponding contract encryption key. The second layer of encryption uses the requester's public key to process the contract encryption key, achieving precise assignment of exclusive decryption capabilities and further enhancing transmission security.

[0045] Step 5-4 sends the encapsulated contract encryption key, data resource identifier, and data usage contract digest as authorization credentials, achieving the integration of precise target data location, contract integrity verification, and authorization credential delivery.

[0046] Among them, the data resource identifier is used to clearly point to the target data to be accessed, ensuring that the access object is accurate and unbiased; the data uses contract digests, such as in the form of hash values, specifically to verify whether the contract content is complete and has not been tampered with, ensuring the accuracy of rule transmission.

[0047] In Example 8, in step 7, the data requester uses a private key to decrypt and obtain the contract encryption key in a local secure environment, and then decrypts the key contract package to extract the data encryption key and the data usage contract. The data provider is allowed to decrypt the acquired data using the data encryption key only when all terms pass the verification, and the data encryption key is invalidated after the contract terms are satisfied.

[0048] Example 9, the steps to invalidate the data encryption key include: after reaching the number of uses or time specified in the contract, the local security agent automatically clears the corresponding data encryption key from memory and uploads the final state hash value of this session to the main server for evidence storage.

[0049] Example 10: The data usage contract also includes execution environment requirements, which specify the minimum security environment level required for decrypting and using data; the local security environment needs to provide environment proof, and decryption operation permissions are granted after verification.

[0050] By adopting the above technical solution, the private key serves as the requester's exclusive identity credential, which can only be accessed by the requester within their own secure environment, thus mitigating the risk of leakage during private key transmission from the source. The local secure environment constructs an isolation and protection barrier for the decryption operation; environments such as encrypted terminals and secure operating systems fall into this category, effectively preventing external malicious programs from eavesdropping on or stealing the decryption process. After obtaining the contract encryption key through private key decryption, the key contract package is further decrypted to extract the data encryption key and data usage contract, forming a hierarchical decryption chain of private key, contract encryption key, and data encryption key. Each layer of decryption relies on exclusive credentials and a secure environment, ensuring that the core key can only be obtained by authorized requesters in secure scenarios.

[0051] The data usage contract covers core terms such as scope of use and timeliness, constituting the authorization boundary of the data provider. Before enabling the data encryption key, the requesting party must first verify each clause of the contract locally. Specifically, it needs to check whether the current time is within the contract's validity period, confirm that the current use has not exceeded the contract's limit, and ensure that the purpose of data use conforms to the contract agreement. Only when all clauses are satisfied will the data provider allow the requesting party to use the data encryption key to decrypt the data, forming a constraint logic of verifying rules before enabling the key. This local verification mode does not rely on real-time interaction with the main server, which improves verification efficiency and avoids the risk of clauses being tampered with during network transmission, ensuring that data use always stays within the authorized boundaries.

[0052] The data usage contract includes preset expiration trigger conditions, such as usage limits and time limits. For example, the former limits decryption to only three times, while the latter sets a 24-hour validity period. The local security agent, as a security component deployed on the requester's local machine, continuously monitors the key usage and time progress in real time. Once the preset conditions are triggered, the key expiration process is initiated.

[0053] The key to tracing the failure status lies in uploading the final status hash value to the main server for evidence storage. The hash value is generated based on the core information of this session, covering the key expiration time, number of uses, and contract terms execution status, etc. It is unique and immutable, and can serve as an authoritative basis for tracing the failure status.

[0054] A local security environment must be provided with environmental certification and pass compliance verification. Environmental certification serves to demonstrate that the local security environment meets contractual requirements and specifically includes materials such as security level certification reports, security component operation logs, and encryption protocol activation status. The requesting party submits the environmental certification to the local verification module or the verification component associated with the main server. The verification module then checks the authenticity and compliance of the supporting documents against the environmental requirements in the contract. Only after successful verification can the corresponding usage permissions be granted.

[0055] The following specific embodiments illustrate the implementation principle of the present invention: Using the automotive industry supply chain as an application scenario, the leading enterprise is an automotive group, whose core responsibility is to coordinate data sharing across the entire supply chain. The supply chain nodes include three core component suppliers, two logistics companies, and five regional dealers. The component suppliers include Engine Company A and Chassis Company B, while the logistics companies are Warehousing & Logistics (C) and Trunk Logistics (D). Each node focuses on four core aspects: production scheduling, component supply, logistics dispatching, and end-user sales, enabling reliable cross-node exchange of data such as component inventory, logistics progress, and dealer order demands.

[0056] Decentralized supply chain data sharing system architecture construction: The vehicle manufacturer, acting as the lead enterprise in the supply chain, deploys a main server. This server integrates four modules: supply chain data registration, identity authentication, request verification, and record keeping. It only handles coordination, registration, and recording functions and does not store any original node data. Engine Company A, as a core node, deploys a local server and a front-end data exchange gateway. The local server specifically stores real-time inventory data for engine blocks, pistons, and other components. The front-end gateway uses the Sangfor NGAF-1000-B200 model, with built-in access control rules, responding only to access requests authorized by the main server. All other nodes, including Chassis Company B and Warehousing & Logistics Company C, deploy local servers and front-end gateways according to a unified standard. The local servers store their respective core business data: Chassis Company B stores chassis component inventory data, and Warehousing & Logistics Company C stores logistics transportation trajectory data. This constructs a decentralized architecture that combines lead coordination with node autonomy.

[0057] Node registration and trust list establishment: Each node submits complete registration information to the OEM's main server. Engine Company A submits its corporate identity information, data types, and data sharing scope. The corporate identity information includes its Unified Social Credit Code 91310000XXXXXX, contact person, and corresponding permissions. The data types cover engine component inventory data and production capacity data. The sharing scope is limited to the OEM and Warehouse Logistics (C), serving only production scheduling and logistics preparation needs, and is not open to other suppliers or dealers. Warehouse Logistics (C) submits its registration information, including its Unified Social Credit Code 91330000XXXXXX, data types, and sharing scope. The data types involve component storage location data and outbound scheduling data. The sharing scope covers the OEM, Engine Company A, and Chassis Company B, and is used for inventory verification and transportation scheduling.

[0058] The master server rigorously verifies the authenticity of registration information for each node, focusing on the validity of enterprise qualification documents and the match between data types and business scenarios. Upon successful verification, a digital identity certificate is issued to each node. The certificate uses the X.509 standard and contains core information such as the node's public key, enterprise identifier, and validity period. Simultaneously, the master server establishes a node trust list, meticulously recording each node's digital identity certificate information, data types, and shareable scope, providing a basis for subsequent identity verification and request validation.

[0059] Data request initiation and verification: To formulate its production schedule for the first quarter of 2025, the vehicle manufacturer sends a data request to the main server. The request identifier uses a combination of scenario code, enterprise code, data type, and data item ID. Specifically, it is SC001 for the production scheduling scenario, EP002 for Engine Company A, DT003 for inventory data, and DI0001 for engine block inventory quantity. The request is explicitly limited to the formulation of the production schedule for the first quarter of 2025, and the usage period is set to 24 hours, from 8:00 AM on January 5, 2025 to 8:00 AM on January 6, 2025.

[0060] Engine Company A pre-builds a semantic mapping table locally, binding its local code KC-001 with the aforementioned global identifier code to ensure the compatibility of the encoding system during data interaction. Upon receiving a request, the main server executes a dual verification process: first, it verifies the legitimacy of the requesting vehicle manufacturer's identity by comparing its digital identity certificate with its trust list information; second, it verifies the compliance of the request scenario by checking whether the production scheduling scenario is within the shareable scope registered by Engine Company A. If Engine Company A confirms that it has authorized the scenario, the verification process proceeds smoothly to the next stage.

[0061] Authorization requests and dynamic keys, usage restriction settings: The main server initiates an authorization request to Engine Company A. Based on its own data sharing strategy, and considering that the engine block is a core component requiring strict control over its usage, Engine Company A decides to grant authorization and triggers a dynamic access key and usage restriction setting process. The main server first generates a structured data usage contract, explicitly limiting the scope of use to the formulation of production scheduling plans for the first quarter of 2025, maintaining a timeliness consistent with the request deadline of 24 hours, limiting the number of uses to 2, allowing only vehicle manufacturers to decrypt and view the data twice, and setting output restrictions, prohibiting data export and supporting only online viewing.

[0062] The main server then generates a data encryption key K1, constructed using the AES-256 encryption algorithm. K1 and the aforementioned data usage contract are then encapsulated into a key contract package. Next, a contract encryption key K2 is generated based on the RSA-2048 algorithm. The key contract package is first encrypted using K2, and then the OEM's public key, obtained from the trust list, is used to encrypt and encapsulate K2, resulting in encrypted K2. Finally, the main server sends encrypted K2, the corresponding data resource identifier, and the SHA-256 digest of the data usage contract as authorization credentials to the OEM.

[0063] Authorization credential issuance and data access: The main server issues a temporary access token and authorization certificate to the OEM. The temporary access token is valid for 24 hours and uses the random string TOKEN-20250105-XXXX. The OEM performs decryption and environment verification operations in a local secure environment. This secure environment deploys an encryption server that complies with ISO27001 information security certification. The OEM first uses its own private key to decrypt the ciphertext K2 to obtain the contract encryption key K2, and then uses K2 to decrypt the ciphertext contract package to extract the data encryption key K1 and the data usage contract.

[0064] The local verification module compares the data with the execution environment requirements of the contract to verify whether it meets the conditions such as a security level no lower than ISO27001 and the activation of the TLS 1.3 encryption protocol. It submits the ISO27001 certification report and server encryption protocol operation logs to the OEM. Upon successful verification, decryption access is granted. Simultaneously, the local verification module further verifies the contract terms, confirming that the current time is 9:00 AM on January 5, 2025, within the 24-hour timeframe, this is the first use and does not exceed the two-use limit, the purpose aligns with production scheduling requirements, and all terms are verified successfully.

[0065] The vehicle manufacturer accesses Engine Company A's front-end gateway using a temporary access token. After verifying the token's validity, Engine Company A's gateway encrypts the engine block inventory data using the data encryption key K1, generating an encrypted data block. The current engine block inventory is 500 units. The encrypted data block is transmitted to the vehicle manufacturer via a TLS 1.3 secure channel.

[0066] In a secure local environment, the vehicle manufacturer decrypts encrypted data blocks using the data encryption key K1 to obtain the raw data for 500 engine block inventories. It then calls a local semantic mapping table to convert the global identifier code into its own internal code PRD-ENG-001, which corresponds to the engine block inventory data. After conversion, the system directly connects to the production scheduling system, providing data support for the formulation of the production plan for the first quarter of 2025.

[0067] The main server records and tracks the entire data interaction process, fully documenting key milestones such as the vehicle manufacturer's data request for production scheduling initiated at 8:30 AM on January 5, 2025, Engine Company A's authorization completed at 8:40 AM, and the vehicle manufacturer's access to the data at 9:00 AM, forming a complete interaction chain archive. Engine Company A can use the main server's record query module, by entering its own enterprise code EP002, to query the accessed record where the accessing party is the vehicle manufacturer, the access time is 9:00 AM on January 5, 2025, and the access purpose is production scheduling, ensuring the compliance of data usage.

[0068] At 8:00 AM on January 6, 2025, the data usage contract expired. The local security agent deployed by the OEM on the encryption server automatically cleared the data encryption key K1 from memory. At the same time, a final state hash value for this session was generated, constructed using the SHA-256 algorithm. The hash value included information such as K1 being invalid, usage count being 1, and expiration date. The hash value was uploaded to the main server for record-keeping to ensure that the key expiration operation was traceable.

[0069] This case study, through the aforementioned implementation process, achieves trusted exchange, controllable use, and traceability of data across all nodes of the automotive supply chain. Vehicle manufacturers accurately obtain component inventory data to support production scheduling, while Engine Company A maintains ownership and control of its own data throughout the entire process. No data leaks or misuse occur, and all interactions can be recorded and traced through the main server. This effectively solves core problems in traditional supply chain data sharing, such as high security risks, weak control capabilities, and difficulties in code adaptation.

[0070] The above are all preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Therefore, all equivalent changes made in accordance with the structure, shape and principle of the present invention should be covered within the scope of protection of the present invention.

Claims

1. A method for decentralized and trusted data exchange control in an enterprise supply chain, characterized in that, Includes the following steps: Step 1: Establish a decentralized supply chain data sharing system architecture, with the chain leader enterprise deploying the main server and each participating enterprise deploying local servers and front-end gateways as nodes; Step 2: Each node enterprise submits registration information to the main server, each participating enterprise signs an electronic agreement, the main server issues digital identity certificates to each node, establishes a node trust list, and establishes a coding and identification system corresponding to data resources; Step 3: The data requester initiates a data request to the master server. The data request includes the identifier code, usage scenario, and usage period of the required data. Step 4: The main server verifies the identity of the data requester and whether the request is within the scope of the registered data sharing scenario; Step 5: The master server sends an authorization request to the data provider. The provider decides whether to authorize based on its own policy and sets dynamic access keys and usage restrictions. Setting up dynamic access keys and usage restrictions includes the following sub-steps: Step 5-1: The main server responds to the data provider's authorization for the data request and generates a structured data usage contract. The data usage contract defines at least one of the following: the scope of data use, timeliness, number of uses, and output restrictions. Step 5-2: Generate a data encryption key for encrypting the target data, and encapsulate the data encryption key and the data usage contract together to form a key contract package; Step 5-3: Encrypt the key contract package using the contract encryption key, and encapsulate the contract encryption key using the public key of the data requester. Step 5-4: Send the encapsulated contract encryption key, data resource identifier, and data usage contract digest as authorization credentials to the data requester; Step 6: After authorization is granted, the main server issues a temporary access token and encryption key to the data requester. Step 7: The data requester directly accesses the provider's front-end data gateway with the access token to obtain the encrypted data block. The data provider uses a dynamic key to encrypt the data, and the key is transmitted to the data requester through a secure channel. Step 8: The data requester uses the key to decrypt the data and converts the identifier encoding into an internally understandable data format locally through a semantic mapping table; In step 1, the specific method for constructing the decentralized supply chain data sharing system architecture is as follows: Establish a chain leader enterprise in the supply chain. The chain leader enterprise deploys and maintains a master server as the coordination and registration center for supply chain data sharing. Each participating enterprise acts as a node, deploying a local data server and a front-end data exchange gateway to provide a controllable data access interface to the outside world; The decentralized supply chain data sharing architecture adopts the principle of decentralized storage. The original data is kept locally on each node and can only be accessed remotely through an authorization mechanism. It is not stored centrally on the main server.

2. The decentralized and trusted data exchange control method in an enterprise supply chain according to claim 1, characterized in that, In step 2, the registration information of the node enterprise includes the enterprise identity and the data resource sharing directory. The data resource sharing directory includes the data type and the scope of data sharing.

3. The decentralized and trusted data exchange control method in an enterprise supply chain according to claim 2, characterized in that: All data requests, authorizations, and access records are logged on the main server; The data provider has the authority to query the access records of shared data. The access records include the visitor, access time, and access purpose.

4. The decentralized and trusted data exchange control method in an enterprise supply chain according to claim 3, characterized in that: In step 3, the identification code adopts a combination structure of scenario code, enterprise code, data type, and data item ID. Each node can customize the mapping relationship between local code and identification code.

5. The decentralized and trusted data exchange control method in an enterprise supply chain according to claim 4, characterized in that: In step 7, the data requester uses its private key to decrypt and obtain the contract encryption key in a local secure environment, and then decrypts the key contract package to extract the data encryption key and the data usage contract. The data provider is allowed to decrypt the acquired data using the data encryption key only when all terms pass the verification, and the data encryption key is invalidated after the contract terms are satisfied.

6. The decentralized and trusted data exchange control method in an enterprise supply chain according to claim 5, characterized in that: The steps to invalidate the data encryption key include: after reaching the number of uses or time specified in the contract, the local security agent automatically removes the corresponding data encryption key from memory and uploads the final state hash value of this session to the main server for record-keeping.

7. A decentralized and trusted data exchange control method for an enterprise supply chain according to claim 6, characterized in that: The data usage contract also includes execution environment requirements, which specify the minimum security environment level required for decryption and data usage; the local security environment must provide proof of the environment and grant decryption operation permissions after verification.

Images