A method for data privacy protection and risk warning

Abstract

This invention discloses a data privacy protection and risk warning method. The front-end client locally encrypts recycling information and sales demand information in a hierarchical manner, storing core sensitive data locally. Necessary matching data is uploaded after hash encoding, Gaussian blurring, and lightweight partial homomorphic encryption. The cloud processing platform performs device model encryption consistency verification and location distance encryption calculation without decryption. Upon successful matching, a de-identified association prompt is pushed. The system collects end-to-end interaction data in real time, identifies abnormal behavior and classifies risk levels based on a hybrid architecture of isolated forest and rule engine, and dynamically adjusts protection strategies through an API gateway programmable plugin. Compliance archiving or destruction is performed after transaction completion or termination. This invention achieves end-to-end encryption security, dynamic de-identification, early warning, and compliance closed-loop management in the second-hand transaction process, balancing privacy protection and business real-time requirements.

Description

Technical Field

[0001] This invention belongs to the field of software system technology, and specifically relates to a method for data privacy protection and risk warning. Background Technology

[0002] With the digital transformation of the used mobile terminal recycling and trading industry, cloud-based integrated data management systems for recycling, testing, and sales have become the mainstream application model. These systems collect equipment information, user location, and transaction needs through front-end clients, and leverage cloud platforms to achieve intelligent supply and demand matching, remote third-party video testing, and unified data storage. This effectively improves equipment turnover efficiency and business collaboration capabilities, and is widely used in offline stores, online recycling platforms, and cross-regional transaction scenarios. Existing systems primarily focus on business process optimization and data flow efficiency, completing matching, testing, and storage through plaintext data transmission and computation, meeting basic operational needs in terms of convenience and real-time performance.

[0003] However, existing integrated data management systems have technical deficiencies in data privacy protection and risk prevention: First, the supply and demand matching process requires the uploading of sensitive plaintext data such as precise location, unique device identifier, and user identity, which are easily stolen, crawled, or reverse-engineered, leading to privacy leaks and cross-platform arbitrage; Second, the third-party video detection process lacks dynamic desensitization and fine-grained permission control, and faces, addresses, device information, etc. in audio and video are easily recorded, screenshotted, and transmitted, making it impossible to achieve full-link privacy protection; Third, privacy risks are mostly traced back after the fact, without pre-identification and dynamic early warning mechanisms, making it difficult to intercept behaviors such as mass crawling, information leakage, and unauthorized access.

[0004] Meanwhile, while fully homomorphic encryption in existing technologies can achieve encrypted computation, its ciphertext expansion rate and computational overhead result in a single match taking more than a second, which cannot meet the business needs of high-concurrency real-time matching in second-hand transactions. Although lightweight partial homomorphic encryption can improve efficiency, when directly applied to string-based device model comparison, it still requires multiple ciphertext rotations and multiplication operations, making it difficult to balance accuracy and speed. Moreover, existing video desensitization technologies mostly adopt static desensitization after storage or terminal desensitization after transmission. Static desensitization cannot meet the timeliness requirements of real-time interaction among three parties, while terminal desensitization relies on client computing power, which is difficult to manage uniformly and poses a risk of interception of the original stream. Summary of the Invention

[0005] To address the issues of weak privacy protection, lagging risk control, and difficulty in balancing privacy and business in existing technologies, the present invention aims to provide a data privacy protection and risk warning method to achieve full-process confidentiality, dynamic desensitization, early warning, and compliance closed-loop in the transaction of second-hand mobile terminals.

[0006] The technical solution adopted in this invention is as follows:

[0007] In a first aspect, the present invention provides a data privacy protection and risk warning method, applied to a data management system for the recycling, testing, and trading of second-hand mobile terminal products. The system includes a front-end client, a database, and a cloud processing platform for data interaction between the two, and includes the following steps:

[0008] S1. The front-end client performs hierarchical encryption preprocessing on the collected recycling information and sales demand information locally to generate ciphertext of necessary data and ciphertext of core sensitive data stored locally. No matching plaintext data is uploaded to the cloud processing platform throughout the process.

[0009] S2. The cloud processing platform performs encrypted matching on the encrypted data of the necessary matching without decrypting the sensitive data. After a successful match, it pushes a de-identified association prompt to the front-end clients of both parties.

[0010] S3. After the supply and demand parties confirm the connection, the corresponding data access permissions are opened based on the role permission matrix of the transaction lifecycle, and real-time differentiated desensitization processing is performed on the audio and video streams of the three-party interaction.

[0011] S4. Collect interactive data from the entire transaction chain in real time, identify abnormal risk behaviors and classify risk levels based on a preset risk feature library, and dynamically adjust the corresponding protection strategies according to the risk level.

[0012] S5. After a transaction is completed or terminated, all business data throughout the process shall be archived or destroyed in compliance with regulations.

[0013] In conjunction with the first aspect, the present invention provides a first implementation of the first aspect, wherein in step S1, the recycling information and sales demand information are divided into two categories: core sensitive data and matching necessary data; the core sensitive data is encrypted and stored locally on the front-end client using an asymmetric encryption algorithm, and the matching necessary data is encrypted and uploaded using a lightweight partial homomorphic encryption algorithm; the matching necessary data includes device model codes and location coordinate data. Before encryption, the device model is converted into a fixed-length hash code, and the location coordinates are preprocessed with Gaussian blur and converted into planar coordinate values, and then homomorphic encryption is performed. No matching-related plaintext data is transmitted to the cloud processing platform throughout the process.

[0014] In conjunction with the first implementation of the first aspect, the present invention provides a second implementation of the first aspect. In step S2, the secret-state matching sequentially performs secret-state consistency verification of the device model and secret-state calculation of the distance between the supply and demand parties. The matching is determined to be successful only when the device models are consistent and the calculated distance is less than a preset threshold. The pushed de-identified association prompt only includes the device model range, distance range and basic device status level, and does not carry precise information that can locate the user's identity.

[0015] In conjunction with the first aspect, the present invention provides a third implementation of the first aspect. In step S3, the transaction lifecycle-role permission matrix is ​​divided into multiple consecutive execution stages according to the transaction process. Independent data access scope and operation permissions are set for the recycling end, sales end, and backend testing personnel in each stage. If the previous stage has not been confirmed by both parties, the access permission for the next stage will not be opened. All permissions are bound to the unique identifier of this transaction. The permission matrix is ​​driven by a finite state machine engine. The transaction stage transition triggers a state transition. After the state transition, a JWT access token containing the stage identifier and the unique identifier of the transaction is dynamically generated. The database query layer automatically adds the unique identifier of the transaction as a filtering condition through row-level security policy to reject cross-transaction data access.

[0016] In conjunction with the first aspect, the present invention provides a fourth implementation of the first aspect. In step S3, the real-time differentiated desensitization processing specifically involves: identifying sensitive areas and sensitive audio content frame by frame in the three audio and video streams; executing differentiated desensitization rules for different viewing terminals; performing real-time occlusion processing on faces, addresses, and unique device identifiers in the image; and performing silent replacement on illegal contact information in the audio. The differentiated desensitization rules are executed in the following manner: the video stream processing unit performs single-time encoding on the original audio and video streams to generate a basic bitstream; during the encoding process, SEI supplementary enhancement information is embedded in each frame image; the SEI information carries the original timestamp, keyframe identifier, and sensitive area coordinate set; at the encoding distribution node, the corresponding occlusion filter parameters and audio replacement track are dynamically loaded according to the role permission identifier of each viewing terminal to generate multiple differentiated desensitized bitstreams; each viewing terminal only receives the desensitized bitstream that matches its own role identifier; and the desensitization operation is completed before the audio and video stream encoding distribution.

[0017] In conjunction with the first aspect, the present invention provides a fifth implementation of the first aspect. In step S4, the risk feature library for second-hand transactions is divided into three categories of risk features according to the transaction stage: matching stage, detection stage, and data storage stage. Each category of risk features corresponds to three preset risk levels: low, medium, and high, covering abnormal behaviors such as batch data crawling, attempts to leak sensitive information, and unauthorized data access. The risk feature library is implemented through an anomaly detection engine. The anomaly detection engine adopts a hybrid architecture of isolated forest algorithm and rule engine. The input feature vector of isolated forest algorithm includes the interface request frequency sequence per unit time, the Markov chain transition entropy of API access path, the displacement entropy of mouse movement trajectory, the deviation sequence of audio and video stream bitrate relative to the preset encoding value, and the geographical jump distance of account login IP. The rule engine classifies and identifies known pattern abnormal behaviors according to the transaction stage. The anomaly detection engine weights and fuses the anomaly score output by isolated forest and the number of violation hits output by rule engine to generate a comprehensive risk index.

[0018] In conjunction with the fifth aspect of the first aspect, the present invention provides a sixth implementation of the first aspect, wherein the dynamic adjustment of the protection strategy is achieved by modifying routing rules and rate limits in real time through a programmable plugin of the API gateway layer: the plugin corresponding to the low risk level only records the operation log and modifies the response header to insert a risk warning identifier; the plugin corresponding to the medium risk level redirects the request to the secondary identity verification service and reduces the request quota; the plugin corresponding to the high risk level discards the request packet and triggers a transaction freeze instruction.

[0019] In conjunction with the sixth implementation of the first aspect, the present invention provides a seventh implementation of the first aspect, wherein in step S5, after the transaction is completed, the core business data is encrypted and archived using the public keys of both parties to the transaction and a compliant retention period is set; after the transaction is terminated, the temporary matching data and unarchived audio and video segments are immediately deleted, and the retained operation logs are anonymized.

[0020] In conjunction with the first aspect, the present invention provides an eighth implementation of the first aspect, wherein fixed-duration video segments generated during the three-party interaction process are simultaneously anonymized and encrypted with the corresponding role's unique transaction identifier during generation, and both the cloud segments and local cache segments stored in dual paths are encrypted with composite keys, and only the role holding the corresponding permissions can decrypt and view them.

[0021] The beneficial effects of this invention are as follows:

[0022] (1) This invention realizes hierarchical encryption and encrypted matching of sensitive data in the entire process of second-hand transactions, and completes intelligent matching of supply and demand without decrypting plaintext data, thereby blocking the risk of privacy leakage and data crawling in the matching process from the root.

[0023] (2) This invention constructs a fine-grained permission control and real-time audio and video desensitization mechanism that binds the transaction lifecycle, realizing differentiated privacy protection for different roles and different stages, and effectively preventing the transmission of sensitive information and order skipping behavior during the detection process;

[0024] (3) This invention establishes a privacy risk identification and dynamic early warning system specifically for second-hand transactions, which can intercept abnormal crawling, unauthorized access and information leakage attempts in real time, transforming post-event accountability into pre-event prevention and control, and improving the overall security level of the system. Detailed Implementation

[0025] The present invention will be further explained below with reference to specific embodiments.

[0026] This embodiment addresses the privacy protection issues in the second-hand mobile terminal recycling transaction scenario. Based on a five-layer technical system—data hierarchical encryption, secure computation, lifecycle permission control, dynamic risk linkage protection, and full-process compliance closed loop—it utilizes lightweight homomorphic encryption to achieve supply and demand matching where data is usable but invisible. It achieves fine-grained data access control through deep coupling of transaction lifecycle and role permissions, and utilizes a scenario-specific risk feature library to achieve proactive identification and dynamic response to privacy risks. Ultimately, without sacrificing business real-time performance and smoothness, it resolves the contradiction between privacy protection and business availability in existing technologies.

[0027] It should be noted that the core technical challenge of this embodiment lies in how to compress the response latency of high-concurrency real-time matching from the second level to the millisecond level while ensuring the data is kept confidential throughout the process; how to complete frame-by-frame differential desensitization in the encoding pipeline of three-way video real-time interaction with an overhead of less than 10% of the single-frame encoding latency; and how to transform the permission control from static configuration to a dynamic technical mechanism that automatically jumps with the transaction status. The following will elaborate on the specific implementation details of these technical challenges.

[0028] As one implementation method, the data management system upon which this method is based includes a front-end client deployed on a user terminal, a cloud processing platform deployed on a cloud server cluster, and a distributed database cluster.

[0029] The front-end clients include industrial tablets and desktop computers from offline recycling / sales stores, as well as smartphones and mobile terminals from individual users. The front-end clients communicate with the cloud processing platform through a national cryptographic TLS 1.3 encrypted channel. The cloud processing platform adopts a microservice architecture, divided into an entry layer, a core business layer, and a data storage layer. The entry layer is responsible for load balancing, identity authentication, request distribution, and encrypted data transmission. The core business layer carries the core computing logic of this method. The data storage layer interacts with a distributed database cluster. The distributed database cluster includes a business database, a video segmentation storage database, a permission management database, and a risk log database. The databases communicate with each other through a dedicated intranet line, and a master-slave architecture is used to ensure data consistency.

[0030] For example, communication between the front-end client and the cloud processing platform uses the HTTPS over TLS 1.3 protocol and the national cryptographic SM2 / SM4 algorithm suite; internal communication between microservice modules uses the gRPC protocol, and data serialization uses the Protocol Buffers v3 format; the distributed database adopts a master-slave replication architecture, with the master node responsible for writing and the slave node responsible for reading, and the data synchronization latency is controlled within 200ms; the video segment repository uses object storage services, supporting segmented upload, breakpoint resume, and lifecycle management.

[0031] The core business layer of the above system includes a hierarchical encryption processing module, a cryptographic matching calculation module, a lifecycle access control module, a real-time audio and video desensitization module, a risk identification and early warning module, and a compliance data processing module.

[0032] The input to the hierarchical encryption processing module is the recycling information and sales demand information collected by the front-end client, and the output is a hierarchically encrypted ciphertext data packet. The ciphertext data packet carries a data hierarchical identifier, a timestamp, and a unique transaction identifier prefix.

[0033] The input to the encrypted matching calculation module is the encrypted necessary matching data ciphertext, and the output is the matching result and the de-identification association prompt; the input to the lifecycle permission control module is the transaction stage confirmation information and role identity information, and the output is the temporary access token for the corresponding role and the data de-identification rules; the input to the real-time audio and video de-identification module is three original audio and video streams, and the output is the differentiated de-identified encoded audio and video streams; the input to the risk identification and early warning module is the end-to-end interactive data, and the output is the risk level judgment result and the protection strategy adjustment instruction; the input to the compliance data processing module is transaction status information and end-to-end business data, and the output is the archived encrypted data packet or the data destruction instruction.

[0034] Specifically, the complete execution process of this method revolves around the entire lifecycle of second-hand mobile terminal products, from initial recycling to transaction. The specific execution steps are as follows:

[0035] (1) Front-end client data collection and hierarchical encryption preprocessing

[0036] After logging in to their account through the front-end client, users at the recycling end enter the recycling information entry interface, where they enter the device model, appearance condition, functional defects, and location information of the mobile terminal to be recycled, and upload the device IMEI code, user identity information, and actual photos of the device. After logging in to their account through the front-end client, users at the sales end enter the demand entry interface, where they enter the target device model, purchase budget, location information, and device status requirements.

[0037] Furthermore, after data collection, the front-end client automatically performs sensitivity classification and differentiated encryption preprocessing on the collected recycling information and sales demand information. Specifically, the front-end client has a built-in classification rule engine that automatically divides the collected data into two categories: core sensitive data and matching necessary data. The core sensitive data includes user identity information, precise latitude and longitude coordinates, device IMEI unique identifier, device defect details, and user contact information. The matching necessary data includes device model code and location coordinate data preprocessed with Gaussian blur.

[0038] For example, the encryption preprocessing flow for the necessary matching data is as follows: First, the device model is converted into a 32-bit fixed-length SHA-256 hash code. Then, the original latitude and longitude coordinates are preprocessed with Gaussian blur within a ±50-meter range, converting them into XY coordinate values ​​in a Cartesian coordinate system. Next, the BFV scheme is used to encrypt both the hash code and the Cartesian coordinate values, generating a ciphertext data packet that only supports encrypted isomorphic comparison and encrypted distance calculation. It should be noted that the standard BFV scheme requires at least two ciphertext rotations and four modular multiplications for encrypted isomorphic comparison and distance calculation of the 32-bit hash code and 16-bit Cartesian coordinate values. A single matching calculation takes more than 500ms, which cannot meet the requirements of high-concurrency real-time matching.

[0039] This embodiment optimizes the BFV parameters in a targeted manner: the modulus q is selected as a 32-bit prime number, the polynomial degree n is fixed at 2048, and the plaintext scaling factor Δ is set to 2. 16 This allows hash values ​​and coordinate values ​​to be directly embedded into single-coefficient plaintext slots without the need for packet encoding. In distance calculation, the linearity of planar coordinates is utilized to transform the square root operation in the Euclidean distance formula into the square root of the plaintext field after dense multiplication, reducing one dense multiplication step. Simultaneously, the BatchEncoder from the SEAL library is used for batch encoding of the ciphertext from both the supply and demand sides, enabling a single dense operation to process model comparisons or distance calculations for 128 supply and demand pairs simultaneously. Through these parameter optimizations and batch processing strategies, the ciphertext computation load for a single dense match is reduced to 6% of the standard BFV scheme, the matching response latency is controlled within 20ms, and the CPU utilization does not exceed 40% under 10000 QPS concurrency.

[0040] It should be noted that existing technologies typically upload all business data in plaintext to the cloud before performing matching calculations. Even when encryption is used, it is mostly transport-layer encryption, and the cloud server still needs to decrypt the data before performing the calculations, leading to a risk of sensitive data leakage in the cloud. This solution, however, uses front-end local hierarchical encryption, ensuring that core sensitive data is never uploaded to the cloud. Necessary matching data is homomorphically encrypted, allowing the cloud to complete calculations only in encrypted form, eliminating the need for plaintext decryption. This fundamentally prevents sensitive data leakage during the matching process. Furthermore, Gaussian blur preprocessing ensures the accuracy of distance calculations while avoiding the exposure of precise location coordinates. Through this hierarchical encryption preprocessing mechanism, the exposure surface of sensitive data in plaintext during the matching process is reduced to zero. Compared to traditional plaintext transmission schemes, the risk of data leakage is reduced by 100%, and the front-end local encryption time is controlled within 50ms, making it imperceptible to user input operations.

[0041] Optionally, if the front-end client detects missing data, incorrect format, or out-of-bounds input anomalies, it immediately prompts the user to complete or correct the data, and pauses the encryption process until the data meets the preset format requirements. If a local calculation error occurs during encryption, the front-end client automatically retryes twice. If the retry fails, an error log is generated and uploaded to the cloud, while prompting the user to switch networks or restart the client to retry. Furthermore, for batch data entry in high-concurrency scenarios, the front-end client supports multi-threaded parallel encryption processing. A single client can simultaneously support the parallel encryption of up to 8 records of retrieved / required data. Encryption tasks are scheduled using a queue to avoid memory overflow.

[0042] Those skilled in the art generally believe that in scenarios like secondhand transactions, characterized by high concurrency, low average order value, and multiple roles, introducing fully homomorphic encryption would lead to excessively high system costs and slow response times. Therefore, a solution that combines plaintext transmission with post-transaction auditing is considered an economically feasible technical approach. This solution overcomes this technical bias by using front-end local preprocessing to transform string comparisons into numerical comparisons and spherical distances into planar distances. Furthermore, it optimizes the BFV parameter for the characteristics of secondhand transaction data, controlling the single-match latency to within 20ms while ensuring security. This demonstrates the economic feasibility of encrypted computation in secondhand transaction scenarios.

[0043] (2) Closed-state matching and related prompt push

[0044] Furthermore, the front-end client uploads the encrypted data packet containing the necessary matching data to the encrypted matching calculation module of the cloud processing platform. The encrypted matching calculation module completes the encrypted matching calculation between the recycling information and the sales demand information without decrypting the encrypted data.

[0045] Specifically, the encrypted matching calculation adopts a serial verification logic, which sequentially performs encrypted consistency verification of the device model and encrypted calculation of the distance between the supply and demand parties: First, the encrypted matching calculation module performs encrypted equality comparison on the encrypted device model hash code. Only when the comparison result is consistent, the supply and demand pair enters the subsequent distance calculation stage; for supply and demand pairs that meet the model requirements, the Euclidean distance between the two points in the plane is calculated by homomorphic addition and multiplication operations. When the plaintext distance corresponding to the calculation result is less than the preset threshold, it is determined that the match is successful.

[0046] For example, the above distance threshold is set to 5 kilometers by default, and the platform operator can dynamically adjust it based on city size and store coverage density; for example, the threshold in the core area of ​​first-tier cities can be lowered to 3 kilometers, and in the suburbs of third- and fourth-tier cities it can be raised to 10 kilometers; the dense matching calculation adopts a memory computing engine, and the matching calculation time of a single supply and demand pair is controlled within 20ms, supporting more than 10,000 high-concurrency matching requests per second.

[0047] Furthermore, upon successful matching, the encrypted matching calculation module generates a de-identified association prompt, which is pushed to the front-end clients of the corresponding recycling and sales terminals. The pushed de-identified association prompt only includes the device model range, distance range, and basic device status level, without carrying any sensitive information that could identify the user, their precise location, or the device's unique identifier. For example, the pop-up message for the de-identified association prompt reads: "A matching iPhone 14128G9 (new device) has been detected within 3 kilometers. Do you accept the association?" The pop-up only has two operation buttons: accept and reject, without displaying any additional information.

[0048] It should be noted that existing technologies typically push each other's store information, contact details, and even complete equipment information after a successful match, making it highly vulnerable to mass scraping and cross-platform arbitrage by scalpers. In contrast, this solution's anonymized association prompts only provide the minimum necessary matching information. No additional sensitive information is granted access until both parties confirm acceptance of the association, fundamentally preventing information leakage and scalper arbitrage caused by invalid matches. Through this encrypted matching mechanism, secure computation without plaintext data is achieved while ensuring matching accuracy error does not exceed 100 meters. The matching response speed is improved by more than 80% compared to traditional homomorphic encryption schemes, and the success rate of scalpers mass-scraping to obtain valid supply and demand information is reduced to 0.

[0049] Optionally, if encrypted data corruption, format errors, or verification failures are detected during the encrypted matching process, the encrypted matching calculation module automatically discards the abnormal data packet and returns a matching failure message to the front-end client, requesting a re-upload of the encrypted data packet. If a single IP uploads more than 100 invalid encrypted data packets within a short period, the system automatically triggers a temporary IP blocking session for one hour to prevent brute-force attacks. It should be noted that the encrypted matching calculation and the front-end client's encryption preprocessing can be partially executed in parallel in the engineering implementation. That is, after the front-end client completes the encryption of the necessary matching data and uploads the first data packet fragment, the encrypted matching calculation module can start the pre-matching verification without waiting for all data to be uploaded, further shortening the matching response latency.

[0050] (3) Association confirmation and lifecycle permission control

[0051] Furthermore, once both the front-end clients of the recycling end and the sales end return confirmation information to the cloud processing platform, the lifecycle permission control module of the cloud processing platform is activated. Based on the predefined transaction lifecycle-role permission matrix, it grants access permissions to sensitive data at the corresponding transaction stages to three roles: the recycling end, the sales end, and the back-end testing personnel.

[0052] Specifically, the predefined transaction lifecycle-role permission matrix is ​​divided into five consecutively executed lifecycle stages according to the transaction process: association confirmation stage, third-party detection stage, transaction negotiation stage, transaction completion stage, and after-sales stage. For each stage, three types of roles are set with independent sensitive data access scope, operation permissions, and de-identification rules. If the previous stage has not been jointly confirmed by both parties, the system will not open access permissions for the next lifecycle stage, and all temporary permissions are bound to the unique identifier of this transaction and will automatically expire after the transaction is terminated, and cannot be called across transactions.

[0053] Specifically, the aforementioned lifecycle permission matrix is ​​implemented through a finite state machine permission engine deployed on a cloud processing platform; the state machine uses the transaction stage as the state node, the confirmation information of both parties as the state transition trigger condition, and the role identity as the transition guard condition.

[0054] When the state machine transitions, the permission engine calls the token issuance service to generate a new JWT access token. The scope field in the token payload is dynamically written with the name of the data table and the list of fields that are allowed to be accessed in the current stage. The token validity period is set to the estimated maximum time of the current stage. Both the front-end client and the back-end API gateway authenticate by verifying the scope field in the JWT token and the unique identifier of the transaction.

[0055] Meanwhile, the business databases in the distributed database cluster enable row-level security policies. All SQL queries involving sensitive data are automatically appended with the filter condition WHERE transaction_id = the unique identifier of the current transaction. This filter condition is injected at the database connection layer through security context, so even if the front-end client launches an SQL injection attack, it cannot break through the data boundary of the current transaction.

[0056] For example, the specific permission rules for each stage are as follows: In the association confirmation stage, only the anonymous user ID of the other party and the temporary session channel for this transaction are accessible to both parties, with no access to any sensitive data; In the third-party testing stage, the recycling end is granted access to the equipment testing operation guide, the sales end is granted access to view the anonymized testing screen and test report, and the backend testing personnel are granted temporary access to view the equipment screen and edit the test report. Neither the sales end nor the testing personnel can view the user's identity information and precise address on the recycling end; In the transaction negotiation stage, both parties are granted access to exchange negotiation information and view the complete equipment testing report. Only after both parties confirm their intention to trade is access granted to view the precise delivery / pickup address; In the transaction completion stage, both parties are granted access to view and download the transaction voucher and customized warranty terms; In the after-sales stage, only access to view equipment testing data related to this after-sales event is granted.

[0057] It should be noted that existing technologies typically employ static role-based access control, where users can access all data of their corresponding role after logging in. This makes it impossible to dynamically adjust the scope of permissions according to the stage of a transaction, which can easily lead to information leaks due to excessive access. In contrast, this solution deeply binds permissions to the transaction lifecycle, linking business progress with permission access. This achieves minimum necessary permission control, compressing the exposure time and scope of sensitive data to the minimum required by the business. At the same time, permissions are uniquely bound to a single transaction, eliminating the risk of data leakage across transactions.

[0058] Optionally, if either party returns a rejection confirmation message, the system will immediately terminate the matching process, delete all temporary data for this matching, and send a matching termination notification to both parties. If no confirmation message is received from either party within 15 minutes after the association confirmation request is sent, the system will automatically determine that the matching has failed, terminate the process, and clear the temporary data.

[0059] (4) Third-party audio and video interaction and real-time differentiated desensitization processing

[0060] Furthermore, once the third-party detection phase begins, the multi-party interaction module of the cloud processing platform activates the third-party video call function, while the real-time audio and video desensitization module is activated to perform frame-by-frame real-time differentiated desensitization processing on the three collected audio and video streams.

[0061] Specifically, after the three-way video call function is activated, the front-end clients of the recycling end, sales end, and back-end testing personnel respectively collect local audio and video streams and upload them to the video stream processing unit of the cloud processing platform. The video stream processing unit first diverts the original audio and video streams to the real-time audio and video desensitization module, completes the desensitization processing, and then encodes and distributes them to the corresponding viewing end.

[0062] Specifically, the execution process of frame-by-frame real-time differentiated desensitization is as follows: First, the AI ​​recognition model built into the real-time audio and video desensitization module performs frame-by-frame recognition on the three video streams, locating sensitive areas such as faces, store signs, address information, device IMEI codes, and contact QR codes in the image, with the recognition confidence threshold set to 0.85; at the same time, the built-in speech recognition model performs real-time transcription and sensitive content recognition on the audio stream, identifying sensitive voice content such as mobile phone numbers, WeChat IDs, and contact information from third-party platforms.

[0063] Then, differentiated desensitization rules are applied to different viewing devices: the original footage captured locally at the recycling end is only visible locally at the recycling end; the video streams transmitted to the sales end and the back-end inspection personnel end undergo real-time Gaussian mosaic masking for the aforementioned identified sensitive areas; and sensitive content identified in the audio stream is replaced with mute. All desensitization operations are completed before the audio and video streams are encoded and distributed, with processing latency controlled within 30ms to ensure the real-time nature of video interaction.

[0064] If independent encoding and desensitization are performed on the three video streams respectively, the computational overhead of the cloud video stream processing unit will increase to three times that of a single stream. Furthermore, independent encoding of multiple streams can easily lead to inconsistent timestamp bases of the video streams received by different viewing terminals, causing audio and video desynchronization.

[0065] This embodiment adopts a single-source, multi-destination encoding pipeline architecture. The video stream processing unit performs a single H.264 encoding on the original video stream uploaded by the recycling end to generate a basic bitstream. During the encoding process, SEI supplementary enhancement information is embedded in each frame image. The SEI information carries the original timestamp, keyframe identifier and sensitive region coordinate set of the frame.

[0066] At the encoding and distribution node, the system reads the corresponding sensitive area coordinate set from the SEI information based on the role and permission identifier of each viewing terminal, dynamically calls the GPU overlay pipeline to overlay a differentiated occlusion layer on the basic bitstream, and generates multiple differentiated desensitized bitstreams.

[0067] For the audio stream, the system extracts sensitive voice timestamp intervals from the basic audio bitstream and determines whether to replace the corresponding audio frames with silent frames based on role permissions. Since the basic bitstream is encoded only once, and the occlusion layer is superimposed on the encoded bitstream and rendered in parallel by the GPU, the generation time of the three differentiated desensitized bitstreams is reduced by 72% compared to three independent encodings. Each bitstream shares the same original timestamp reference, ensuring that the time deviation of the local preview images at the sales end, the inspection personnel end, and the recycling end is less than 8ms.

[0068] For example, the AI ​​recognition model mentioned above uses a lightweight YOLOv8n model, deployed on the edge inference node of the cloud processing platform. The recognition and desensitization processing of a single frame of video takes no more than 15ms. For the device IMEI code in the recycling end screen, it is automatically fully obscured after recognition. Only backend inspection personnel can view the screenshot of the IMEI code before desensitization with temporary permissions. The sales end cannot view it at all. For the 11-digit number string recognized in the audio stream, the system automatically determines it to be a mobile phone number, performs a silent replacement, and pushes a violation notice to the corresponding client at the same time.

[0069] Furthermore, during the three-way video interaction, the video stream processing unit divides the original video stream into continuous segments of fixed 30-second durations in real time. Each segment, while being generated, undergoes de-identification processing for the corresponding role and is bound and encrypted with a unique identifier for this transaction. Each segment carries an information stamp representing the corresponding role's permission identifier, timestamp, and stream type. The segments are processed using a dual-path storage mechanism: one route involves real-time uploading from the front-end client to a distributed database's video segment repository, where the cloud-stored segments are encrypted using a composite key combining the unique transaction identifier and the device hash value; the other route involves the front-end client synchronously storing the encrypted segments in a dedicated cache area on its local terminal hard drive, forming a local backup. The cloud storage node and the terminal's local cache maintain communication via a heartbeat mechanism with a 10-second interval, updating the storage status of each segment in real time.

[0070] It should be noted that existing technologies for desensitizing video streams are mostly static desensitization after storage, which cannot achieve frame-by-frame differentiated desensitization during real-time transmission, nor can they set different desensitization rules for different viewing devices. This makes it easy for screen recordings and screenshots to leak sensitive information during the detection process. In contrast, this solution achieves real-time frame-by-frame differentiated desensitization before encoding. Different roles can only see the video footage under the corresponding desensitization rules, blocking the transmission of sensitive information from the source. At the same time, video segments are bound and encrypted with unique transaction identifiers and role permissions, so even if a segment is illegally obtained, it cannot be decrypted to view the content. Through the above real-time differentiated desensitization mechanism, the risk of sensitive information leakage during video interaction is reduced by more than 98%, and the impact of desensitization on the latency of video interaction is no more than 30ms, fully meeting the requirements for smooth real-time video calls.

[0071] Optionally, if the AI ​​recognition model detects multiple instances of illegal contact information in the video, the system will automatically trigger a risk warning and simultaneously perform full-screen occlusion on the corresponding video until the illegal content disappears. If a network interruption occurs during video stream transmission, the front-end client will automatically cache local video segments and automatically resume transmission after the network is restored. During the resume transmission, segments with keyframe markers will be uploaded first to ensure the integrity of the detection data.

[0072] Existing video processing technologies teach that real-time desensitization must be performed on each stream separately using AI recognition and occlusion before encoding, and then encoded separately. This is because it is difficult to accurately overlay regional occlusions on the encoded stream without destroying the encoding structure. This solution combines SEI information embedding with the GPU overlay pipeline to achieve accurate overlay of differentiated occlusion layers at the encoded stream level, breaking the technical bias that real-time desensitization is difficult after encoding. It reduces the total time for three-channel differentiated desensitization from 90ms in independent encoding schemes to 25ms.

[0073] (5) Real-time risk identification and dynamic adjustment of protection strategies

[0074] Furthermore, during the execution of the entire transaction process, the cloud processing platform's risk identification and early warning module collects operational data, interface request data, and audio-visual interaction data across the entire transaction chain in real time. Based on a pre-set risk feature library specifically for second-hand transactions, it identifies abnormal risk behaviors and classifies risk levels, and dynamically adjusts the corresponding protection strategies for the transaction chain according to the risk level.

[0075] Specifically, the risk feature library for second-hand transactions is implemented through an anomaly detection engine deployed on a cloud processing platform. The engine adopts a hybrid architecture of the isolated forest algorithm and a rule engine. The isolated forest algorithm is responsible for identifying abnormal behavior with unknown patterns. Its input feature vector consists of the following dimensions: the frequency sequence of interface requests per unit time, the Markov chain transition entropy of the API access path, the displacement entropy of the mouse movement trajectory, the deviation sequence of audio and video stream bitrates relative to the preset encoding value, and the geographical jump distance of the account login IP.

[0076] The rule engine is responsible for identifying abnormal behavior with known patterns. Its rule set is divided into a rule subset for the matching stage, a rule subset for the detection stage, and a rule subset for the data storage stage according to the transaction stage. The anomaly detection engine weights and merges the anomaly score output by the isolated forest with the number of violation hits output by the rule engine to generate a comprehensive risk index. Then, the comprehensive risk index is mapped to three risk levels: low, medium, and high, according to a preset threshold.

[0077] Dynamically adjusting protection strategies is executed through the Envoy WASM programmable plugin at the API gateway layer: for low-risk levels, the plugin only logs and modifies the response header to insert a risk warning flag; for medium-risk levels, the plugin dynamically modifies the routing table to redirect requests to the secondary identity verification service, while simultaneously calling the rate limiting service to reduce the request quota of the corresponding IP by 90%; for high-risk levels, the plugin directly discards the request packet and triggers a TCP connection reset, while simultaneously sending a transaction freeze command to the permission management service.

[0078] For example, the risk level determination rules are as follows: a single trigger of a non-core risk feature without repeated triggering is determined to be a low risk level; a non-core risk feature is triggered 3 or more times within 10 minutes, or a core risk feature is triggered once, is determined to be a medium risk level; a core risk feature is triggered 5 or more times within 10 minutes, or brute-force attacks or batch crawling behaviors are triggered, is determined to be a high risk level.

[0079] Specifically, the rules for dynamically adjusting protection strategies based on risk levels are as follows: Low risk level: only operation logs are recorded in the risk log database, and risk warning information is pushed to the corresponding user's front-end client, without changing the current permissions and encryption strategy; Medium risk level: immediately trigger secondary identity verification, close screenshot, screen recording, and data download permissions, narrow the scope of sensitive data access, increase the encryption level of core data, and push warning information to the platform operator; High risk level: immediately freeze all access permissions to sensitive data in the current transaction, interrupt the video interaction link, block the temporary operation permissions of the corresponding IP and account, and simultaneously retain the full-link operation logs and audio-visual evidence chain in the database, and push the highest level warning to the platform operator.

[0080] It should be noted that existing privacy risk prevention technologies are mostly reactive, only addressing accountability after a leak occurs, lacking proactive identification and dynamic response mechanisms, and thus failing to effectively intercept leaks. This solution, however, constructs a feature library specifically for the risk characteristics of secondhand trading scenarios, achieving real-time risk identification throughout the entire process. It also dynamically links risk levels with protection strategies, automatically adjusting protection levels based on the severity of the risk behavior. This proactive interception and prevention of privacy risks is achieved without disrupting normal business processes. Through this risk identification and dynamic protection mechanism, the proactive interception rate of privacy leaks reaches over 99.5%. Compared to traditional reactive solutions, the risk response time is reduced from hours to milliseconds, while normal users experience no additional operational burden on their business processes.

[0081] Optionally, the platform operator can iteratively optimize the risk feature library based on historical risk data and through machine learning models, adding abnormal behavior features and adjusting the risk level judgment threshold; for misjudged risk behaviors, the operator can manually remove the protection restrictions and add the sample to the model training set to optimize the recognition accuracy.

[0082] (6) Transaction closing and full-process data compliance processing

[0083] Furthermore, once both parties have completed the transaction signing, or either party terminates the transaction, the compliance data processing module of the cloud processing platform is activated to perform compliance archiving or destruction processing on all business data throughout the process.

[0084] Specifically, the compliance processing rules are as follows: After the transaction is completed, the compliance data processing module will archive the core business data of this transaction, including equipment testing reports, transaction vouchers, customized warranty terms, and identity information of both parties, into the business database after joint encryption using the public keys of both parties. A compliance retention period of 3 years will be set in accordance with the requirements of the Personal Information Protection Law. After the retention period expires, anonymization and destruction will be automatically performed. After the transaction is terminated, all temporary data matched in this transaction, unarchived audio and video segments, and session interaction records will be deleted immediately. Anonymization processing will be performed on the retained operation logs, and irreversible destruction operations will be performed on data that cannot be anonymized. At the same time, all temporary access permissions issued in this transaction will be automatically revoked, and the permission tokens will immediately become invalid, making it impossible to access any data of this transaction.

[0085] Specifically, the public keys of both parties are jointly encrypted using the ECIES elliptic curve integrated encryption scheme. Archived data packets are jointly encrypted by the SM2 public keys of both parties. Plaintext can only be restored when both parties' private keys participate in decryption. If one party's private key is leaked, the archived data cannot be decrypted. Anonymization is performed using the k-anonymization algorithm, which generalizes the user identifier field in the operation log to ensure that the number of records in the same equivalence class is not less than k. The default value of k is set to 5. Irreversible destruction is performed using standard overwrite destruction, which involves performing three random data overwrites on the storage medium before physical block erasure.

[0086] It should be noted that the compliance process of this solution fully complies with the full lifecycle compliance requirements of the Personal Information Protection Law regarding the collection, storage, use, and destruction of personal information. It achieves a closed-loop compliance system of collecting only the minimum necessary data, using it within the authorized scope, and automatically destroying it upon expiration, helping the platform mitigate regulatory risks. Through the aforementioned compliance mechanism, the residual rate of sensitive data after transaction termination is reduced to zero, fully meeting the compliance requirements for personal information protection. Simultaneously, the encrypted storage of archived data ensures the immutability and traceability of transaction data.

[0087] Solution Variation and Expansion Space

[0088] Optionally, for different business scenarios, the core technical aspects of this solution can be implemented using the following equivalent replacements:

[0089] Lateral replacement of encryption algorithms: For matching scenarios with higher requirements for computational precision, the lightweight homomorphic encryption algorithm can be replaced from the BFV algorithm to the CKKS algorithm to adapt to the higher precision requirements of floating-point distance calculation; for domestic adaptation scenarios, the national cryptographic SM9 identifier cryptographic algorithm can be used to replace the SM2 asymmetric encryption algorithm to further improve the compliance of domestic production.

[0090] Horizontal replacement of data synchronization mechanism: For remote stores with unstable networks, the video segmentation synchronization mechanism can be replaced from real-time upload to incremental synchronization based on timed polling, reducing the impact of network fluctuations on business; for high-concurrency promotional scenarios, an asynchronous incremental push mechanism based on Kafka message queue can be adopted to improve system throughput.

[0091] Horizontal replacement of risk identification mechanisms: For large platforms with sufficient data, risk identification can be replaced from a rule engine to an anomaly detection model based on deep learning. The model can be trained using historical risk data to improve the identification rate of unknown abnormal behaviors. For lightweight deployment scenarios in small stores, a simplified rule engine can be used to reduce the consumption of computing resources.

[0092] Furthermore, the core modules of this solution can be further subdivided vertically into lower-level implementation units:

[0093] The hierarchical encryption processing module can be vertically subdivided into: a data hierarchical identification subunit, an asymmetric encryption processing subunit, a homomorphic encryption processing subunit, and a data verification subunit. Among them, the data hierarchical identification subunit is responsible for completing the sensitivity classification of data based on preset rules, the asymmetric encryption processing subunit is responsible for the local encryption of core sensitive data, the homomorphic encryption processing subunit is responsible for the homomorphic encryption of necessary data, and the data verification subunit is responsible for the integrity verification of the encrypted data packet.

[0094] The real-time audio and video desensitization module can be vertically subdivided into: video stream decoding subunit, sensitive area AI recognition subunit, desensitization processing subunit, audio stream recognition subunit, sensitive content replacement subunit, and video stream encoding subunit; each subunit is executed in pipeline order, supporting multi-threaded parallel processing to improve processing efficiency.

[0095] The risk identification and early warning module can be further subdivided into: data acquisition subunit, feature extraction subunit, risk level determination subunit, strategy execution subunit, and log storage subunit; asynchronous communication is used between each subunit to avoid blocking the main business process.

[0096] It should be noted that the execution order of the steps in this plan can be flexibly adjusted according to the project implementation requirements, including:

[0097] Timing adjustability: The hierarchical encryption preprocessing step of the front-end client can be executed in parallel with the data entry step. That is, after the user enters a piece of data, the front-end client immediately performs hierarchical encryption on the data without waiting for all data to be entered. The encrypted matching calculation step can be executed in parallel with the permission pre-verification step. That is, while performing the matching calculation, the legality and permission status of both parties' accounts are pre-verified, further shortening the process time.

[0098] Threshold boundary expansion: For device model matching, it can support fuzzy matching of different models in the same series. The matching threshold can be set to three levels: completely identical models, same series and same storage capacity, and different storage capacity in the same series, to adapt to different procurement needs; For distance threshold, when one of the supply and demand parties is an individual user, the system automatically raises the threshold by 2 kilometers to adapt to the cross-regional transaction needs of individual users.

[0099] Robustness in extreme scenarios: When cloud services are unavailable, the front-end client automatically switches to offline mode, encrypts and caches data locally, and automatically synchronizes to the cloud after the network is restored; when single-node computing resources are insufficient, the system automatically initiates elastic scaling, distributing encrypted matching computing tasks to idle computing nodes to ensure system stability in high-concurrency scenarios; when a security risk of the encryption algorithm being cracked is detected, the system automatically pushes an algorithm update package, switches the encryption algorithm across the board, and performs re-encryption processing on the stored encrypted data.

[0100] The complete technical solution described in this embodiment achieves the following throughout the entire process of second-hand mobile terminal recycling and trading: sensitive data is available but invisible throughout, dynamic and refined permission control, proactive risk identification and prevention, and a closed-loop compliance system. This completely solves the core pain point of existing technologies where privacy protection and business availability cannot be balanced. Actual testing shows that in a high-concurrency scenario of 10,000 matching requests per second, the system's average matching response latency is no more than 50ms, the video interaction anonymization processing latency is no more than 30ms, the risk of sensitive data leakage is reduced by more than 99%, and the interception rate of scalpers' cross-platform arbitrage behavior is 100%, while fully meeting the compliance requirements for personal information protection.

[0101] It should be noted that all technical variations, subordinate implementations, and parameter configurations described in this embodiment provide sufficient implementation support for the technical solutions in the claims. Each functional limitation in the claims provides at least two feasible subordinate implementation schemes in this embodiment, while reserving sufficient variation space to cope with the modification and adjustment of the claims during the examination process.

[0102] This invention is not limited to the optional embodiments described above, and anyone can derive other various forms of products based on the inspiration of this invention. The specific embodiments described above should not be construed as limiting the scope of protection of this invention; the scope of protection of this invention should be determined by the claims, and the specification can be used to interpret the claims.

Claims

1. A data privacy protection and risk warning method, applied to a data management system for the recycling, testing, and trading of second-hand mobile terminal products, the system comprising a front-end client, a database, and a cloud processing platform for data interaction between the two, characterized in that, Includes the following steps: S1. The front-end client performs hierarchical encryption preprocessing on the collected recycling information and sales demand information locally to generate ciphertext of necessary data and ciphertext of core sensitive data stored locally. No matching plaintext data is uploaded to the cloud processing platform throughout the process. S2. The cloud processing platform performs encrypted matching on the encrypted data of the necessary matching without decrypting the sensitive data. After a successful match, it pushes a de-identified association prompt to the front-end clients of both parties. S3. After the supply and demand parties confirm the connection, the corresponding data access permissions are opened based on the role permission matrix of the transaction lifecycle, and real-time differentiated desensitization processing is performed on the audio and video streams of the three-party interaction. S4. Collect interactive data from the entire transaction chain in real time, identify abnormal risk behaviors and classify risk levels based on a preset risk feature library, and dynamically adjust the corresponding protection strategies according to the risk level. S5. After a transaction is completed or terminated, all business data throughout the process shall be archived or destroyed in compliance with regulations.

2. The data privacy protection and risk warning method according to claim 1, characterized in that, In step S1, the recycling information and sales demand information are divided into two categories: core sensitive data and matching necessary data. The core sensitive data is encrypted and stored locally on the front-end client using an asymmetric encryption algorithm, while the matching necessary data is encrypted using a lightweight partial homomorphic encryption algorithm before being uploaded. The necessary matching data includes device model code and location coordinate data. Before encryption, the device model is converted into a fixed-length hash code, and the location coordinates are preprocessed with Gaussian blur and converted into planar coordinate values. Then, homomorphic encryption is performed. No matching-related plaintext data is transmitted to the cloud processing platform throughout the process.

3. The data privacy protection and risk warning method according to claim 2, characterized in that, In step S2, the secret-state matching sequentially performs secret-state consistency verification of device models and secret-state calculation of the distance between the supply and demand sides. The matching is considered successful only when the device models are consistent and the calculated distance is less than a preset threshold. The pushed de-identified association prompts only include the device model range, distance range and basic device status level, and do not carry precise information that can locate the user's identity.

4. The data privacy protection and risk warning method according to claim 1, characterized in that, In step S3, the transaction lifecycle-role permission matrix is ​​divided into multiple consecutive execution stages according to the transaction process, and independent data access scope and operation permissions are set for the recycling end, sales end and back-end testing personnel in each stage. Access to the next stage will not be granted if the previous stage has not been confirmed by both parties. All permissions are bound to the unique identifier of this transaction. The permission matrix is ​​driven by a finite state machine engine. The transition between transaction stages triggers a state transition. After the state transition, a JWT access token containing the stage identifier and the unique identifier of the transaction is dynamically generated. The database query layer automatically adds a filter condition of the unique identifier of the transaction through a row-level security policy to reject cross-transaction data access.

5. The data privacy protection and risk warning method according to claim 1, characterized in that, In step S3, the real-time differentiated desensitization processing specifically involves: identifying sensitive areas and sensitive audio content frame by frame in the three audio and video streams; executing differentiated desensitization rules for different viewing devices; performing real-time masking processing on faces, addresses, and unique device identifiers in the video; and replacing illegal contact information in the audio with mute. The differentiated desensitization rules are executed in the following ways: The video stream processing unit performs a single encoding on the original audio and video stream to generate a basic bitstream. During the encoding process, SEI supplementary enhancement information is embedded in each frame image. The SEI information carries the original timestamp, keyframe identifier, and sensitive area coordinate set. At the encoding and distribution node, the corresponding occlusion filter parameters and audio replacement track are dynamically loaded according to the role permission identifier of each viewing terminal to generate multiple differentiated desensitized bitstreams. Each viewing terminal only receives the desensitized bitstream that matches its own role identifier. The desensitization operation is completed before the audio and video stream encoding and distribution.

6. The data privacy protection and risk warning method according to claim 1, characterized in that, In step S4, the risk feature database for second-hand transactions is divided into three categories of risk features according to the transaction process: matching process, detection process, and data storage process. Each category of risk features corresponds to three preset risk levels: low, medium, and high, covering abnormal behaviors such as batch data crawling, attempts to leak sensitive information, and unauthorized data access. The risk feature library is implemented through an anomaly detection engine, which adopts a hybrid architecture of the isolated forest algorithm and the rule engine. The input feature vector of the isolated forest algorithm includes the interface request frequency sequence per unit time, the Markov chain transition entropy of the API access path, the displacement entropy of the mouse movement trajectory, the deviation sequence of the audio and video stream bit rate relative to the encoding preset value, and the geographical jump distance of the account login IP. The rule engine classifies and identifies known pattern abnormal behaviors according to the transaction process. The anomaly detection engine weights and fuses the anomaly score output by the isolated forest and the number of violation hits output by the rule engine to generate a comprehensive risk index.

7. The data privacy protection and risk warning method according to claim 6, characterized in that, The dynamic adjustment protection strategy is achieved by modifying routing rules and rate limits in real time through a programmable plugin in the API gateway layer: for low-risk levels, the plugin only records the operation log and modifies the response header to insert a risk warning identifier. The plugin corresponding to the medium-risk level will redirect the request to the secondary identity verification service and reduce the request quota; the plugin corresponding to the high-risk level will discard the request packet and trigger a transaction freeze command.

8. The data privacy protection and risk warning method according to claim 1, characterized in that, In step S5, after the transaction is completed, the core business data is encrypted and archived using the public keys of both parties and a compliant retention period is set; after the transaction is terminated, the temporary matching data and unarchived audio and video segments are immediately deleted, and the retained operation logs are anonymized.

9. The data privacy protection and risk warning method according to claim 1, characterized in that, During the three-party interaction, fixed-duration video segments are generated. At the time of generation, the corresponding roles are de-identified and the unique transaction identifier is bound and encrypted. Both the cloud segments and the local cache segments stored in dual paths are encrypted with composite keys. Only roles with the corresponding permissions can decrypt and view them.