Data exchange and execution method, system and device for protecting data privacy and medium

Abstract

The invention relates to the technical field of data security, and relates to a data exchange and execution method, system and device for protecting data privacy and a medium, the method comprises the following steps: acquiring sandbox environment information created by a user side, dynamically creating and configuring an isolation container, loading sample data based on the operation authority of the user side, and storing the sample data in a database; generating a temporary access link with time limit and returning the temporary access link to the user side; writing an algorithm in the sandbox environment for the user side according to the access link to perform static security detection to obtain a detection result, and auditing the detection result and algorithm metadata to obtain a security detection report; auditing the security detection report and the algorithm metadata, setting access authority, encrypting the algorithm, and transmitting the encrypted algorithm to a production environment to execute the algorithm; after the algorithm is executed, the output result is encrypted and stored, and the encrypted result is authorized to be delivered to the corresponding user side, so that the user side decrypts the result through the private key. The algorithm has confidentiality and integrity during cross-environment transmission.

Description

Technical Field

[0001] This disclosure relates to the field of data security technology, and in particular to data exchange and execution methods, systems, devices and media for protecting data privacy. Background Technology

[0002] With the gradual establishment of a data element circulation system, the demand for collaboration between second-party devices and algorithm users is rapidly increasing. Algorithm users hope to utilize the high-quality data held by second-party devices for model training, inference analysis, or customized development, while second-party devices need to open up their computing capabilities while ensuring data security and compliance. However, in the existing data circulation and collaborative computing technology system, data sharing always faces security risks such as privacy leaks, unauthorized access, illegal copying, and difficulty in auditing. This makes it impossible for algorithm developers to directly obtain real data, and second-party devices also find it difficult to verify the algorithm's behavior and execution compliance.

[0003] Current mainstream solutions typically employ either data anonymization followed by sharing or local algorithm execution. While the former mitigates privacy risks through anonymization and data masking, the masking process often disrupts data structure, distribution characteristics, and key correlations, making it difficult for the algorithm to obtain accurate evaluation results on sample data, thus leading to unpredictable actual production execution performance. The latter requires the second device to open its internal computing resources for external algorithm execution, but lacks a unified algorithm review mechanism and isolation between the development and production environments. External algorithms may carry malicious code, access to the first device, network requests, and other high-risk operations, posing a security threat to the first production device.

[0004] On the other hand, existing primary equipment typically lacks end-to-end encryption and auditing mechanisms for algorithms, from development, packaging, transmission, review to execution. Most solutions only manage access at the data layer, while the algorithm package lacks effective confidentiality and integrity protection during transmission, making it highly susceptible to tampering or replacement during cross-environment transmission. Furthermore, the lack of a trusted authentication system between different parties and inconsistent algorithm metadata structures make it impossible to ensure consistency between algorithm input / output fields and the production dataset. During production environment execution, the lack of field-level dynamic anonymization capabilities also means that data accessed by the algorithm is immediately exposed to the developers, failing to achieve minimum authorization and controlled access.

[0005] Therefore, the key issue is how to ensure data confidentiality without compromising data integrity when transmitting algorithms across environments. Summary of the Invention

[0006] To address the aforementioned technical problems, this disclosure provides a method, system, device, and medium for data exchange and execution that protects data privacy. The method includes: The first device obtains the sandbox environment information created by the user terminal, dynamically creates and configures the isolation container, loads sample data based on the user terminal's operation permissions, generates a temporary access link with time limit and returns it to the user terminal; The first device performs static security checks on the user terminal based on the access link in the sandbox environment using an algorithm, obtains the detection results, and reviews the detection results and the algorithm metadata to obtain a security detection report. The second device reviews the security detection report and the algorithm metadata and sets access permissions. When the review is passed, the first device encrypts the algorithm and transmits it to the production environment for execution. After the algorithm is executed, the output result is encrypted and stored, and the encrypted result is authorized to be delivered to the corresponding user terminal so that the user terminal can decrypt the result using a private key.

[0007] Furthermore, when the audit is approved, the first device encrypts the algorithm and transmits it to the production environment for execution, including: When the review is approved, the first device calculates the hash value of the algorithm and generates a one-time symmetric key and a random initialization vector; The algorithm packet is encrypted using the symmetric key in a cryptographic block chaining mode to obtain the encrypted algorithm packet; The symmetric key is encrypted and encapsulated using the public key of the second device to obtain the encapsulated symmetric key; The hash value is signed using the private key of the first device; The random initialization vector, the encrypted algorithm package, the encapsulated symmetric key, and the signature are transmitted as a transport packet to the production environment for algorithm execution via a dedicated channel.

[0008] Furthermore, the random initialization vector, the encrypted algorithm package, the encapsulated symmetric key, and the signature are transmitted as a transport packet to the production environment via a dedicated channel for algorithm execution, including: After receiving the transmission packet, the production environment decrypts the encapsulated symmetric key using the private key of the second device, verifies the signature using the public key of the first device, compares the integrity of the hash value, and uses the symmetric key and random initialization vector to decrypt and obtain the original algorithm packet. The original algorithm package is submitted to the distributed computing engine for execution in an isolated queue.

[0009] Furthermore, before the first device obtains the user's information about creating a sandbox environment, the following steps are included: Receive login requests from users and verify user identity information; An access token is issued based on the user's identity information. The user terminal's operating permissions are obtained based on the access token.

[0010] Furthermore, during the execution of the algorithm, authorized data is loaded via a data access proxy according to the caller's permissions; The authorized data is subject to field-level dynamic desensitization rules, and the accessed fields and the number of records are recorded.

[0011] Furthermore, the second device sets fine-grained field access policies for the algorithm during the audit process.

[0012] Furthermore, it also includes: Record full-link audit logs, trigger alarms when abnormal behavior is detected and support immediate revocation of permissions, and calculate data usage and billing based on the audit logs.

[0013] This disclosure also provides a data exchange and execution system that protects data privacy, including: The acquisition module is used by the first device to acquire information about the sandbox environment created by the user terminal, dynamically create and configure the isolation container, load sample data based on the user terminal's operation permissions, generate a temporary access link with time limit and return it to the user terminal; The detection module is used by the first device to perform static security detection on the user terminal based on the access link in the sandbox environment, obtain the detection result, and review the detection result and the algorithm metadata to obtain a security detection report. The review module is used by the second device to review the security detection report and the algorithm metadata and set access permissions. When the review is passed, the first device encrypts the algorithm and transmits it to the production environment for execution. The authorization module is used to encrypt and store the output result after the algorithm is executed, and authorize the delivery of the encrypted result to the corresponding user terminal so that the user terminal can decrypt the result using a private key.

[0014] This disclosure also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the data exchange and execution method for protecting data privacy.

[0015] This disclosure also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the data exchange and execution method for protecting data privacy.

[0016] The technical solution provided in this disclosure has the following advantages compared with the prior art: This disclosure achieves reliable authentication and permission issuance before sandbox application through identity authentication, and dynamically creates an isolated sandbox environment, enabling developers to conduct algorithm development and verification in a production-compatible controlled environment, thus avoiding the exposure of raw data from the source. During the algorithm submission stage, static security detection and algorithm metadata verification can automatically detect and block potential high-risk calls and metadata mismatch issues, reducing the burden of manual review and improving review efficiency. After review by a second device, the transmission packet, which uses encryption with a one-time symmetric key and random initialization vector, public key encapsulation of the symmetric key, and signature of the first device's private key, reaches the production environment through a dedicated channel, forming a trust chain of confidentiality, integrity, and non-repudiation to prevent tampering and leakage during cross-environment transmission. This ensures the confidentiality and integrity of the algorithm during cross-environment transmission. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0018] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the data exchange and execution method for protecting data privacy as described in an embodiment of this disclosure; Figure 2 As described in the embodiments of this disclosure Figure 1 A schematic diagram of the encryption method for the algorithm in the first device; Figure 3 This is a schematic diagram of a data exchange and execution system for protecting data privacy as described in an embodiment of this disclosure. Detailed Implementation

[0020] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0021] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0022] Figure 1 This is a schematic diagram of the data exchange and execution method for protecting data privacy as described in the embodiments of this disclosure, as follows: Figure 1 As shown, a data exchange and execution method for protecting data privacy includes: Step S1: The first device obtains the sandbox environment information created by the user terminal, dynamically creates and configures the isolation container, loads sample data based on the user terminal's operation permissions, generates a temporary access link with time limit and returns it to the user terminal. In this embodiment, after the first device obtains the sandbox environment creation information from the user client, it first verifies the user client's identity and quota in the identity authentication and permission management module (based on Open Authorization 2.0 (OAuth 2.0), JSON Web Token (JWT), and Multi-Factor Authentication (MFA)) to confirm the maximum concurrency and resource limit for the user client to create sandboxes (e.g., a maximum of 2 CPU cores and 8GB of memory per sandbox). Then, it calls the sandbox management module API to dynamically create an independent isolated container in the Kubernetes (container orchestration first device) cluster (the container is either a Jupyter Notebook (interactive notebook environment) or a VScode (code editor, Visual Studio Code) development environment). It configures resource quotas, ServiceAccounts, and network policies for this container to achieve network isolation (allowing access only to internal platform services and prohibiting direct access to the public network), and mounts a read-only development image and a pre-built toolchain (such as a Spark client (distributed computing engine, Apache Spark) and Pandas (Python). (Data analysis library, etc.); The first device automatically loads sample data (driven by the data management module and desensitization rules) with the same structure as production data (the sample data is driven by the data management module and desensitization rules) according to the user's operation permissions, generates a temporary access link with time limit for the sandbox (the link embeds a short-term JWT or one-time token and records the mapping and expiration time in the database) and returns it to the user. At the same time, the creation event and associated metadata are recorded in the audit module. This embodiment can quickly and automatically provide developers with a production-compatible but secure testing environment, ensuring that there is no exposure of raw data, resources are controlled, network is restricted, and operations are traceable during the development process, significantly reducing the risk of data leakage and improving development efficiency and reproducibility.

[0023] Step S2: The first device performs static security checks on the user terminal based on the access link in the sandbox environment using an algorithm, obtains the detection results, and reviews the detection results and algorithm metadata to obtain a security detection report. In this embodiment, when a user develops and submits an algorithm in the sandbox environment via a temporary access link, the first device triggers static security detection. This involves a rule-based scan and Abstract Syntax Tree (AST) analysis of the algorithm package's source code and dependency list, identifying and labeling high-risk calls (e.g., calls from the first device, file writing, external network requests, deserialization, etc.). Simultaneously, it verifies the integrity and consistency of the algorithm's metadata (checking whether the input and output schemas match the target dataset and whether dependencies are usable in a production environment). The static detection results and algorithm metadata are integrated into a security detection report and stored in the review queue. If necessary, the first device can perform a dry run of sample data within the sandbox to verify the output format and basic compatibility. The entire detection and review process is logged in the audit module, recording the detection rule version, detection time, and the information of the detector (automatic or manual). This automatically detects and blocks potential leaks or unauthorized actions before the algorithm enters production, ensuring the compatibility of algorithm metadata with production data, reducing the burden of manual review, and providing verifiable detection evidence, thereby improving the overall security and review efficiency of the first device.

[0024] Step S3: The second device reviews the security detection report and algorithm metadata and sets access permissions. When the review is passed, the first device encrypts the algorithm and transmits it to the production environment for execution. In this embodiment, after receiving the security detection report and algorithm metadata, the second device reviews the algorithm function and risk report on the platform interface and sets field-level and operation-level access permissions (e.g., allowing reading but prohibiting export, anonymizing during reading, or only returning statistical summaries); after approval by the second device (data provider), the first device enters the encryption and signature transmission process: firstly, it calculates the SHA-256 hash (Secure Hash Algorithm 256) of the algorithm packet and generates a one-time AES-256 symmetric key and a random initialization vector (IV), using AES-256 (Cipher Block Chaining) mode. Chaining encrypts the algorithm package; then, it encapsulates the AES key using the public key of the second device and hashes and signs the algorithm package using the private key of the first device. Finally, the IV, encrypted data, encapsulation key, and signature are combined into a transmission packet and transmitted to the production environment via a dedicated encrypted channel. Upon receiving the packet, the production environment uses the private key of the second device to decapsulate the AES key, verifies the signature using the public key of the first device, and compares the hashes to confirm integrity and origin. Only after successful verification can the packet be decrypted and the algorithm published to a controlled artifact repository for scheduling execution (scheduled to a scheduler pool isolated by client / tenant, used for Spark scheduling isolation). Through the combination of one-time symmetric key encapsulation, asymmetric key encapsulation, signature, and hash verification, the confidentiality, integrity, and non-repudiation of the algorithm during cross-environment transmission are ensured, preventing tampering or leakage during transmission or replacement, and giving the second device control over the scope of authorization and usage.

[0025] Step S4: After the algorithm is executed, the output result is encrypted and stored, and the encrypted result is authorized to be delivered to the corresponding user terminal so that the user terminal can decrypt the result using the private key.

[0026] In this embodiment, when the algorithm is executed in the production environment (Spark cluster) in the isolated queue, the algorithm obtains authorized data through the DataProxy. Before returning the data, the proxy performs dynamic desensitization on sensitive fields according to the field-level desensitization rules set by the second device (e.g., phone number, ID card mask, or numerical binning), and continuously records the accessed fields and the number of read records during execution. After the algorithm is executed, the first device encrypts and stores the output result (it can use symmetric encryption and encapsulate the symmetric key with the requester's public key or directly encrypt the result with the receiver's public key) and writes the result hash, execution parameters, and access records into the audit module. The platform delivers the encrypted result to the corresponding user terminal according to the authorization. The user terminal decrypts the result using its private key and can initiate a second execution to verify the result. The audit module charges based on the recorded access volume and field usage at a preset unit price and automatically deducts and settles the billing in the accounting module. This step ensures the confidentiality and traceability of the execution result throughout the transmission and storage process, protects the interests of the second device and the requester, supports result verification and dispute resolution, and achieves transparent charging based on usage through a refined metering and billing mechanism, enhancing the platform's compliance and feasibility.

[0027] In another embodiment of this disclosure, Figure 2 As described in the embodiments of this disclosure Figure 1 A schematic diagram of the encryption method for the algorithm in the first device; as shown. Figure 2 As shown, step S3, when the review is approved, the first device encrypts the algorithm and transmits it to the production environment for algorithm execution, including: step S31, when the review is approved, the first device calculates the hash value of the algorithm and generates a one-time symmetric key and a random initialization vector; step S32, the algorithm package is encrypted using the symmetric key in a cryptographic block chaining mode to obtain the encrypted algorithm package; step S33, the symmetric key is encrypted and encapsulated using the public key of the second device to obtain the encapsulated symmetric key; step S34, the hash value is signed using the private key of the first device; step S35, the random initialization vector, the encrypted algorithm package, the encapsulated symmetric key, and the signature are transmitted as a transmission packet to the production environment for algorithm execution through a dedicated channel.

[0028] In this embodiment, the first device first calculates the SHA-256 hash value of the algorithm packet and generates a one-time AES-256 symmetric key and a random initialization vector (IV) using a secure random number generator. Then, it encrypts the algorithm packet using the AES-256 symmetric key in Cipher Block Chaining (CBC) mode (using appropriate padding as needed) to obtain the encrypted algorithm packet. The first device then uses the public key of the second device to encrypt and encapsulate the one-time symmetric key (symmetric key encapsulation), and signs the previously calculated hash value using the private key of the first device. Finally, the IV, the encrypted algorithm packet, the encapsulated symmetric key, and the signature are combined into a transmission packet, which is sent to the production environment through a controlled dedicated encrypted channel. By combining the one-time symmetric key, asymmetric key encapsulation, and hash signature, the confidentiality, integrity, and non-repudiation of the algorithm packet during cross-environment transmission are achieved, avoiding the risk of key reuse and improving the transmission's resistance to tampering, thereby ensuring the trust chain between the second device and the platform.

[0029] In another embodiment of this disclosure, step S35, transmitting the random initialization vector, the encrypted algorithm package, the encapsulated symmetric key, and the signature as a transmission packet to the production environment for algorithm execution via a dedicated channel, includes: after receiving the transmission packet, the production environment decrypts the encapsulated symmetric key using the private key of the second device, verifies the signature using the public key of the first device and compares the integrity of the hash value, and uses the symmetric key and the random initialization vector to decrypt and obtain the original algorithm package; and submits the original algorithm package to the distributed computing engine for execution in an isolated queue.

[0030] In this embodiment, the production environment first uses the private key of the second device to decrypt the encapsulated symmetric key to recover the one-time AES-256 key. Then, it uses the public key of the first device to verify the signature and compares the hash value contained in the signature with the recalculated hash of the decrypted algorithm package to confirm integrity. After the hash and signature verification are successful, the encrypted algorithm package is decrypted using the symmetric key and IV to obtain the original algorithm package. Subsequently, the original algorithm package is submitted to an isolated queue in a distributed computing engine (such as a Spark cluster) for execution. This strict decryption, signature verification, and integrity verification process is implemented on the production side. Only verified algorithms can enter the controlled execution environment, reducing the risk of malicious or tampered algorithms being executed in the production environment and ensuring execution reliability and traceability.

[0031] In another embodiment of this disclosure, before step S1, the step of the first device obtaining information about the user terminal creating a sandbox environment, the method includes: receiving a login request from the user terminal and verifying the user terminal's identity information; issuing an access token based on the user terminal's identity information; and obtaining the user terminal's operation permissions based on the access token.

[0032] In this embodiment, the first device first receives the login request from the user and verifies it through the identity authentication and permission management module (using OAuth 2.0 and multi-factor authentication (MFA)). After successful verification, a short-term access token (e.g., a JWT token) is issued based on the user's identity information. Based on this, the device obtains or calculates the user's operation permissions and quotas (such as the maximum number of concurrent sandboxes and the range of accessible data) from the permission management sub-device. This access token and permissions are used for subsequent authorization judgments in sandbox creation and sample data loading, and login events are stored in the audit module. Reliable identity authentication and permission acquisition are completed before sandbox creation, ensuring that only users with the corresponding permissions can apply for a sandbox, preventing unauthorized creation and access to sample data, and improving the security and controllability of the first device.

[0033] In another embodiment of this disclosure, during algorithm execution, authorized data is loaded by a data access proxy according to the caller's permissions; field-level dynamic desensitization rules are applied to the authorized data and the number of accessed fields and records is recorded.

[0034] In this embodiment, when the algorithm runs in the production environment, it loads authorized data according to the caller's permissions through a data access proxy (DataProxy). The data access proxy performs field-level dynamic anonymization on the returned data according to the policy configured on the second device (e.g., phone number / ID card masking, value binning or range sorting), and records the list of accessed fields and the number of read records (including timestamps, caller ID, algorithm ID, dataset ID, etc.) in real time. The data access proxy also enforces restrictions such as no export or only allowing statistical summarization. By implementing least privilege access and dynamic anonymization at runtime through DataProxy, the availability of data required for algorithm operation is ensured, while the actual data exposed to the algorithm is minimized, significantly reducing the risk of sensitive information leakage and providing accurate data for measurement, auditing, and post-event traceability.

[0035] In another embodiment of this disclosure, the second device sets fine-grained field access policies for the algorithm during the audit.

[0036] In this embodiment, within the audit interface or policy management module of the second device, the second device can configure access policies for each field of the authorized algorithm (e.g., allowing reading but prohibiting export, desensitizing data according to rules during reading, only allowing the return of aggregate / statistical values, or applying row-level filtering conditions). These policies are issued and enforced by the data access agent and the execution policy engine. Simultaneously, the audit decision and policy configuration are recorded in the audit log and audit log for traceability. By granting the second device precise control over the granularity of data exposure, data misuse and compliance risks are reduced, while providing technical execution guarantees and auditable evidence for the authorized scope agreed upon by both parties.

[0037] In another embodiment of this disclosure, the method further includes: recording end-to-end audit logs, triggering alarms and supporting immediate revocation of permissions when abnormal behavior is detected, and calculating data usage and billing based on the audit logs.

[0038] In this embodiment, the first device generates audit events and writes them to immutable or verifiable audit storage (audit logs) at each stage of the entire chain, including sandbox creation, algorithm submission, static security testing, audit authorization, transmission, production execution, data access, and result delivery. The audit module uses a rule engine to detect abnormal behavior in real time (such as exceeding the threshold for a single read of a sensitive field, frequent large-scale reads within a short period of time, or attempts to export prohibited fields). Once triggered, it issues a real-time alarm and supports the platform or the second device to immediately freeze the relevant account or revoke permissions. At the same time, the number of field accesses and reads recorded in the audit logs is used to calculate data usage based on a preset unit price and trigger automatic billing and settlement processes. Through full-chain auditing and real-time anomaly detection, it achieves pre-emptive protection, in-process interception, and post-event accountability, which not only improves compliance and security response capabilities but also enables transparent billing and revenue distribution based on usage.

[0039] In another embodiment of this disclosure, the first device is deployed using hardware, including: Hardware preparation: Application servers (at least 3, 8-core CPU / 32GB memory), used to deploy the first device microservices and container environment; Spark cluster (1 master, 3 slaves, 16-core CPU / 64GB memory), used to handle large-scale computing tasks; Distributed storage (e.g., initial capacity 10TB), used to store raw data and algorithms; Database server (master-slave architecture): used to store client information, permission configurations, logs, etc.

[0040] Software deployment: Install Kubernetes 1.24+ and Docker 20.10+ (containerization platform) for container orchestration; deploy a Spark 3.3+ cluster and configure dynamic resource scheduling; deploy a PostgreSQL 14+ database (the primary device for relational database management) and a Redis (in-memory key-value database) cache; install core services (identity authentication, sandbox management, etc.) and automate deployment via Helm graph (Kubernetes package manager).

[0041] Security configuration: Configure SSL / TLS certificates to ensure all communication is encrypted; deploy a firewall to restrict cluster access (allowing only necessary ports such as 443 and 8080); initialize an encryption key pair (RSA 2048-bit (Rivest–Shamir–Adleman public key encryption algorithm)) for algorithm signing and data encryption.

[0042] First equipment testing: Verify the sandbox environment creation / destruction function to ensure isolation; test the entire process of algorithm development and execution to check environment consistency; simulate abnormal scenarios (such as malicious code submission, excessive data access) to verify the effectiveness of security mechanisms.

[0043] Registration and Authentication: Submit your company's qualification certificates and complete real-name authentication to obtain the "Second Device" role; Data Upload: Create dataset metadata (name, description, sensitivity level, etc.) on the first device interface; upload data files through an encrypted channel (supporting formats such as comma-separated values ​​(CSV) and columnar storage format (Parquet, Apache Parquet)); configure desensitization rules (such as hiding the middle 4 digits of the phone number) and access pricing (such as 1 yuan per 10,000 records).

[0044] Algorithm Review: Receive algorithm review requests submitted by users, view algorithm functions and security reports; set permissions (e.g., allow the algorithm to read the "income" field but prohibit the export of the original value); approve or reject the request and fill in the reason (e.g., "The algorithm contains network requests, which pose a risk of leakage").

[0045] Monitoring and Revenue: Real-time monitoring of data access frequency and algorithm execution status; monthly revenue settlement, with platform service fees automatically deducted from the first device.

[0046] Specifically, after the user client completes identity authentication, they select "Create Sandbox Environment" on the first device interface, specifying the environment type and resource requirements. The first device verifies the user client's quota (e.g., a maximum of two sandboxes can be created simultaneously) and calls the sandbox management module API. The sandbox management module creates an independent container in the Kubernetes cluster, configures network isolation (allowing communication only with the first device service and prohibiting direct access to the public network), automatically loads the sample data that the user client is authorized to access (with the same structure as production data but with anonymized content), and generates a temporary access link (with time limits). The user client then accesses the sandbox environment through a browser.

[0047] The following is an example of the user-side authentication code: def authenticate_user(username, password, mfa_code): # Verify username, password, and MFA verification code user = User.query.filter_by(username=username).first() if not user or not user.verify_password(password) or not verify_mfa(user.mfa_secret, mfa_code): return None, indicating authentication failed. # Generate JWT tokens containing role information token = create_jwt_token(user.id, roles=[r.name for r in user.roles],expires=3600) return {"token": token}, None Here is an example of code for creating a sandbox: def create_sandbox(user_id, env_type="jupyter"): # Generate a unique environment ID env_id = f"sandbox-{user_id}-{uuid4().hex[:8]}" # Configure Docker containers (Jupyter / VScode images, resource limits, network isolation) container = docker_client.containers.run( image=f"sandbox-{env_type}:v1.0", name=env_id, resources={"cpus": 2, "mem_limit": "8g"}, network="sandbox-isolated", detach=True ) # Load sample data and initialization script load_sample_data(env_id, user_id) return {"env_id": env_id, "access_url": f"https: / / {env_id}.sandbox.com"} Users write interactive analysis code using Jupyter Notebook (an interactive notebook environment) or develop complex algorithms using a code editor (VScode, Visual Studio Code); they test the algorithm using sample data in a sandbox to ensure the algorithm's logic is correct (e.g., model accuracy, output format); the algorithm is packaged according to the first device's specifications (including the main program, dependency list, and metadata); the algorithm is submitted to the data provider, a process that triggers automatic security checks, which statically analyze the code for risky operations (e.g., requests network requests (Python's requests library, Python HTTPlibrary)); the algorithm's metadata is verified to be complete (e.g., whether input and output fields match the target dataset); after passing the checks, the algorithm enters the review queue, awaiting approval from the second device.

[0048] The second device reviews the algorithm's functional description and security test report, and sets data access permissions (such as which fields are allowed to be accessed and whether results can be exported). After approval, the first device encrypts the algorithm package using AES-256 and signs it with the second device's public key. The encrypted algorithm is transmitted to the production environment through a dedicated channel, where it is decrypted and the signature is verified using the private key (to ensure it has not been tampered with). Key preparation phase: First, the first device generates an RSA asymmetric key pair (2048 bits). The private key is securely stored by the first device and used for signing. The public key is publicly distributed and used to verify the signature. A random AES-256 symmetric key is generated for each algorithm transmission, with a completely new key generated for each transmission to avoid the risk of key reuse. The key length is 256 bits, conforming to the Advanced Encryption Standard (AES).

[0049] Encryption and Signature Process: First, the algorithm file is preprocessed, including calculating the SHA-256 hash value of the algorithm file (used for integrity verification), and then the algorithm file and hash value are packaged into a data packet to be transmitted.

[0050] Then comes the AES-256 encryption process. The first step is to encrypt the data packet using a randomly generated AES key. The second step is to use CBC mode (Cipher Block Chaining) and generate a random initialization vector (IV). Finally, the encrypted data is obtained as IV + encrypted data packet (IV does not need to be kept secret).

[0051] Finally, there's the RSA signing process, which involves signing the AES key and the original file hash using the first device's private key. The signature result contains an encrypted version of the AES key (encrypted using the recipient's public key).

[0052] The final transmission packet contains three parts: the encrypted algorithm data packet (including IV), the RSA signature result, and a description of the algorithm parameters used for encryption.

[0053] Decryption and verification process: First, the signature verification process uses the public key of the first device to verify the validity of the signature, then extracts and decrypts the AES key, and finally verifies the consistency between the hash value in the signature and the received data. Next is the AES decryption process, which extracts the IV from the encrypted data packet, then uses the AES key and IV to decrypt the data packet, and finally extracts the original algorithm file and hash value.

[0054] Finally, there is the integrity verification process, which requires recalculating the hash value of the decrypted file and comparing it with the original hash value obtained from decryption to confirm that the file has not been tampered with.

[0055] When a user initiates an execution request, the first device allocates Spark resources based on the data size (e.g., 4 executors for 100GB of data); the Spark engine loads the algorithm and obtains authorized data (automatically anonymized) through the data access broker; during algorithm execution, the first device records data access details (e.g., how many records were read and which fields were accessed); after execution, the results are encrypted and stored, and the first device notifies the user to retrieve the results.

[0056] Here is a sample of key code for submitting Spark tasks: def submitAlgorithmJob(algorithmId: String, datasetId: String,userId: String): String = { / / Verify permissions and obtain algorithm code val algorithm = AlgorithmManager.getDecryptedAlgorithm(algorithmId,userId) / / Configure Spark sessions (resource limits, isolation queues) val spark = SparkSession.builder() .appName(s"job-$algorithmId") .config("spark.executor.cores", 4) .config("spark.scheduler.pool", s"user-$userId") .getOrCreate() / / Load data and execute algorithms via proxy val data = DataProxy.loadAuthorizedData(datasetId, userId, spark) val result = AlgorithmExecutor.run(algorithm, data) spark.stop() return storeEncryptedResult(result, userId) } After the user authenticates their identity, they download the encrypted result and decrypt it using their own private key. If they have any questions about the result, they can initiate a second execution (using the same algorithm and parameters). The audit module will periodically generate reports on the data usage process. The second device can view the number of times the data has been accessed, and the user can view the algorithm execution record. The first device automatically calculates the fee based on the amount of data used (e.g., accessing 1 million records) and deducts it from the user's account. Figure 3 This is a schematic diagram of a data exchange and execution system for protecting data privacy as described in an embodiment of this disclosure. Figure 3 As shown, this disclosure also provides a data exchange and execution system for protecting data privacy, including: The acquisition module 401 is used by the first device to acquire information about the sandbox environment created by the user terminal, dynamically create and configure the isolation container, load sample data based on the user terminal's operation permissions, generate a temporary access link with time limit and return it to the user terminal; The detection module 402 is used by the first device to perform static security detection on the user terminal based on the access link in the sandbox environment using an algorithm, obtain the detection results, review the detection results and algorithm metadata, and obtain a security detection report. The audit module 403 is used by the second device to audit the security detection report and algorithm metadata and set access permissions. When the audit is passed, the first device encrypts the algorithm and transmits it to the production environment for execution. The authorization module 404 is used to encrypt and store the output result after the algorithm is executed, and authorize the delivery of the encrypted result to the corresponding user terminal so that the user terminal can decrypt the result using the private key.

[0057] This disclosure also provides a computer device, including a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement steps of a data exchange and execution method that protects data privacy.

[0058] This disclosure also provides a computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement steps of a data exchange and execution method that protects data privacy.

[0059] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0060] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A data exchange and execution method for protecting data privacy, characterized in that, include: The first device obtains the sandbox environment information created by the user terminal, dynamically creates and configures the isolation container, loads sample data based on the user terminal's operation permissions, generates a temporary access link with time limit and returns it to the user terminal; The first device performs static security checks on the user terminal based on the access link in the sandbox environment using an algorithm, obtains the detection results, and reviews the detection results and the algorithm metadata to obtain a security detection report. The second device reviews the security detection report and the algorithm metadata and sets access permissions. When the review is passed, the first device encrypts the algorithm and transmits it to the production environment for execution. After the algorithm is executed, the output result is encrypted and stored, and the encrypted result is authorized to be delivered to the corresponding user terminal so that the user terminal can decrypt the result using a private key.

2. The data exchange and execution method for protecting data privacy according to claim 1, characterized in that, When the audit is approved, the first device encrypts the algorithm and transmits it to the production environment for execution, including: When the review is approved, the first device calculates the hash value of the algorithm and generates a one-time symmetric key and a random initialization vector; The algorithm packet is encrypted using the symmetric key in a cryptographic block chaining mode to obtain the encrypted algorithm packet; The symmetric key is encrypted and encapsulated using the public key of the second device to obtain the encapsulated symmetric key; The hash value is signed using the private key of the first device; The random initialization vector, the encrypted algorithm package, the encapsulated symmetric key, and the signature are transmitted as a transport packet to the production environment for algorithm execution via a dedicated channel.

3. The method of claim 2, wherein, The random initialization vector, the encrypted algorithm package, the encapsulated symmetric key, and the signature are transmitted as a transport packet to the production environment via a dedicated channel for algorithm execution, including: After receiving the transmission packet, the production environment decrypts the encapsulated symmetric key using the private key of the second device, verifies the signature using the public key of the first device, compares the integrity of the hash value, and uses the symmetric key and random initialization vector to decrypt and obtain the original algorithm packet. The original algorithm package is submitted to the distributed computing engine for execution in an isolated queue.

4. The method of claim 1 to 3, wherein, Before the first device obtains the user's information about creating a sandbox environment, the following steps are included: Receive login requests from users and verify user identity information; An access token is issued based on the user's identity information. The user terminal's operating permissions are obtained based on the access token.

5. The method for data exchange and execution for protecting data privacy according to any one of claims 1 to 3, characterized in that, During the execution of the algorithm, authorized data is loaded via a data access proxy according to the caller's permissions; The authorized data is subject to field-level dynamic desensitization rules, and the accessed fields and the number of records are recorded.

6. The method of claim 1 to 3, wherein, The second device sets fine-grained field access policies for the algorithm during the audit process.

7. The method for data exchange and execution for protecting data privacy according to any one of claims 1 to 3, characterized in that, Also includes: Record full-link audit logs, trigger alarms when abnormal behavior is detected and support immediate revocation of permissions, and calculate data usage and billing based on the audit logs.

8. A data exchange and execution system for protecting data privacy, characterized by, include: The acquisition module is used by the first device to acquire information about the sandbox environment created by the user terminal, dynamically create and configure the isolation container, load sample data based on the user terminal's operation permissions, generate a temporary access link with time limit and return it to the user terminal; A detection module is configured to perform static security detection on the algorithm written by the user terminal in the sandbox environment according to the access link by the first device, obtain a detection result, and perform audit on the detection result and the algorithm metadata to obtain a security detection report; An audit module is configured to perform audit on the security detection report and the algorithm metadata by the second device and set access permission, and when the audit is passed, the first device encrypts the algorithm and transmits the algorithm to a production environment to execute the algorithm; An authorization module is configured to, after the algorithm execution is completed, encrypt and store an output result, and authorize delivery of the encrypted result to the corresponding user terminal, so that the user terminal decrypts the result by using a private key.

9. A computer device, comprising: A computer readable storage medium stores computer readable instructions, and a processor executes the computer readable instructions to implement the steps of the data exchange and execution method for protecting data privacy according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer readable storage medium stores computer readable instructions, and a processor executes the computer readable instructions to implement the steps of the data exchange and execution method for protecting data privacy according to any one of claims 1 to 7.

Images