Privacy protection data classification method and system based on cloud platform

Abstract

The invention discloses a privacy protection data classification method and system based on a cloud platform, and relates to the field of data classification management, and the method comprises the steps: distributing sensitivity tags for different data attributes at a client according to a preset strategy, and carrying out the encryption through selecting a homomorphic encryption public key matched with the tag level, and forming a ciphertext beam containing the ciphertext and the label. And then, at the cloud, guiding a subsequent calculation process by using the tag vector in the ciphertext beam. Through a self-adaptive encryption model, different calculation paths can be dynamically selected to execute homomorphic feature engineering and classification calculation according to whether high-sensitivity data exists in a label or not. According to the method, refinement and isolation processing of data with different sensitivities is realized, an encryption strategy and calculation logic are deeply bound, and dynamic balance between calculation efficiency and security level is realized on the premise of ensuring data security.

Description

Technical Field

[0001] This application relates to the field of data classification management, and more specifically, to a privacy-preserving data classification method and system based on a cloud platform. Background Technology

[0002] With the rapid development of cloud computing and big data technologies, more and more enterprises and organizations are choosing to migrate their data storage and computing tasks to cloud platforms to leverage their powerful computing capabilities and storage flexibility. However, data centralization also brings serious privacy risks. Especially when handling classification tasks involving sensitive data such as personal information and trade secrets, ensuring the confidentiality and security of data throughout the entire process of storage, transmission, and computation while enjoying the convenience of cloud services has become a pressing technical challenge. Therefore, building a solution for privacy-protected data classification in a cloud environment is crucial for promoting the secure and compliant flow and application of data elements.

[0003] To address this challenge, existing technologies have explored various approaches. One common strategy is for the data owner to perform uniform encryption on the entire dataset locally before uploading it to the cloud, using techniques such as fully homomorphic encryption. The cloud then performs classification model calculations in this encrypted state and returns the results to the user for decryption. While this method can protect data privacy to some extent, its core flaw lies in its one-size-fits-all encryption strategy. Real-world datasets are often heterogeneous, with different attributes exhibiting mixed levels of sensitivity. For example, a user's name and ID number are highly sensitive information, while transaction amounts and consumption categories may be moderately sensitive, and the city where the account was opened may be low-sensitive. Applying the highest-strength homomorphic encryption to all attributes, regardless of their sensitivity, not only wastes enormous computational resources and significantly reduces the efficiency of classification tasks, but also makes it impossible to achieve fine-grained access control because all data is bound to the same key system, making it difficult to meet complex business authorization requirements.

[0004] Therefore, how to efficiently, securely, and with controllable access classify encrypted states of datasets with mixed sensitivity attributes in a cloud environment has become a key bottleneck in current technological development. Summary of the Invention

[0005] To overcome the aforementioned problems in the background art, according to one aspect of this application, a privacy-preserving data classification method based on a cloud platform is provided, which includes:

[0006] Encode each attribute in the original data to obtain a set of attribute codes;

[0007] Based on a sensitivity strategy, a sensitivity label is assigned to each attribute code in the set of attribute codes, and based on the sensitivity label, a corresponding homomorphic encryption public key is selected from the client key chain to encrypt each attribute code in the set of attribute codes to obtain a labeled ciphertext bundle.

[0008] The tagged ciphertext bundle and its corresponding public key and relinearization key are uploaded to the cloud to obtain the stored ciphertext bundle and cloud key chain;

[0009] In response to a classification request received in the cloud, the stored ciphertext bundle is parsed based on the cloud key chain to obtain the parsed ciphertext vector and tag vector.

[0010] Based on the label vector, the parsed ciphertext vector is subjected to label-guided homomorphic feature engineering and classification calculation in the cloud to obtain the encryption result, and the encryption result is sent to the client.

[0011] The client decrypts and decodes the encrypted result based on the client key chain to obtain the privacy-protected data classification result.

[0012] According to another aspect of this application, a cloud-based privacy-preserving data classification system is provided, comprising:

[0013] The attribute encoding module is used to encode each attribute in the original data to obtain a set of attribute codes;

[0014] The attribute encryption module is used to assign sensitivity tags to each attribute code in the set of attribute codes based on a sensitivity policy, and to select a corresponding homomorphic encryption public key from the client key chain based on the sensitivity tags to encrypt each attribute code in the set of attribute codes to obtain a tagged ciphertext bundle.

[0015] The data upload module is used to upload the tagged ciphertext bundle and its corresponding public key and relinearization key to the cloud to obtain the stored ciphertext bundle and cloud key chain;

[0016] The parsing module is used to respond to a classification request received in the cloud by parsing the stored ciphertext bundle based on the cloud key chain to obtain the parsed ciphertext vector and tag vector.

[0017] An encryption module is used to perform label-guided homomorphic feature engineering and classification calculation on the parsed ciphertext vector based on the label vector in the cloud to obtain an encryption result, and send the encryption result to the client;

[0018] The decryption module is used by the client to decrypt and decode the encrypted result based on the client's key chain to obtain the privacy-protected data classification result.

[0019] Compared with existing technologies, this application provides a cloud-based privacy-preserving data classification method and system, which proposes a differentiated encryption and adaptive computation method guided by sensitivity tags. This method first assigns sensitivity tags to different data attributes on the client side according to a preset strategy, and then uses a homomorphic encryption public key matching the tag level for encryption, forming a ciphertext bundle containing ciphertext and tags. This differentiated encryption method avoids the resource waste caused by using the highest strength encryption for all data, initially solving the efficiency problem. Next, in the cloud, the tag vector in the ciphertext bundle is used to guide the subsequent computation process. Through an adaptive encryption model, different computation paths can be dynamically selected to perform homomorphic feature engineering and classification computation based on whether high-sensitivity data exists in the tags. This not only achieves refined and isolated processing of data with different sensitivities, meeting flexible access control requirements, but more importantly, it deeply binds the encryption strategy with the computational logic, achieving a dynamic balance between computational efficiency and security level while ensuring data security. This effectively solves the problems of low efficiency and rigid access control in existing solutions when processing mixed sensitive data. Attached Figure Description

[0020] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0021] Figure 1 This is a flowchart of a cloud-based privacy-preserving data classification method according to an embodiment of this application.

[0022] Figure 2 This is a schematic diagram of data flow in a cloud-based privacy-preserving data classification method according to an embodiment of this application.

[0023] Figure 3 This is a flowchart of step 4 in the cloud-based privacy-preserving data classification method according to an embodiment of this application.

[0024] Figure 4 This is a flowchart of step 5 in the cloud-based privacy-preserving data classification method according to an embodiment of this application.

[0025] Figure 5 This is a block diagram of a cloud-based privacy-preserving data classification system according to an embodiment of this application. Detailed Implementation

[0026] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0027] In response to the problems mentioned in the background description, this application proposes a privacy-preserving data classification method based on a cloud platform. Figure 1 This is a flowchart of a cloud-based privacy-preserving data classification method according to an embodiment of this application. Figure 2 This is a schematic diagram illustrating the data flow of a cloud-based privacy-preserving data classification method according to an embodiment of this application. Figure 1 and Figure 2 As shown, the cloud-based privacy-preserving data classification method according to an embodiment of this application includes: Step 1, encoding each attribute in the original data to obtain a set of attribute codes; Step 2, assigning sensitivity labels to each attribute code in the set of attribute codes based on a sensitivity strategy, and encrypting each attribute code in the set of attribute codes by selecting a corresponding homomorphic encryption public key from the client key chain based on the sensitivity labels to obtain a labeled ciphertext bundle; Step 3, uploading the labeled ciphertext bundle and its corresponding public key and relinearization key to the cloud to obtain a stored ciphertext bundle and a cloud key chain; Step 4, responding to a received classification request in the cloud, parsing the stored ciphertext bundle based on the cloud key chain to obtain a parsed ciphertext vector and a label vector; Step 5, performing label-guided homomorphic feature engineering and classification calculation on the parsed ciphertext vector based on the label vector in the cloud to obtain an encryption result, and sending the encryption result to the client; Step 6, the client decrypting and decoding the encryption result based on the client key chain to obtain a privacy-preserving data classification result.

[0028] In step 1, each attribute in the raw data is encoded to obtain a set of attribute codes. It is understood that the raw data often exists in heterogeneous forms, containing various types such as text, numbers, and categories. These raw data formats cannot be directly processed by homomorphic encryption algorithms and subsequent machine learning models. Homomorphic encryption schemes typically operate on specific mathematical structures (such as integer rings or real / complex vector spaces), while classification models also require uniform, standardized numerical vectors as input. Therefore, before performing any encryption operations, the raw data must be preprocessed to convert it into a uniform, computable numerical representation. This resolves the contradiction between data heterogeneity and computational homogeneity, transforming different types of raw attributes into standardized numerical formats through encoding, laying the foundation for subsequent encryption and ciphertext computation.

[0029] In one feasible embodiment of this application, step 1, encoding each attribute in the original data to obtain a set of attribute codes, includes: if the attribute is a numerical attribute, normalizing the attribute to obtain the attribute code; if the attribute is categorical data, performing one-hot encoding on the attribute to obtain the attribute code.

[0030] In the above feasible embodiments, step 1 is as follows: First, the input raw data needs to be parsed to identify the data type of each attribute. For example, a sample of raw data containing user information might be {"Name": "Zhang San", "Age": 35, "Income": 85000, "Occupation": "Engineer", "City": "Beijing"}. In this sample, age and income are identified as numerical attributes, while occupation and city are identified as categorical attributes.

[0031] For identified numerical attributes, such as age and income, normalization will be performed. Normalization aims to map values ​​from different ranges to a uniform, smaller interval [0,1] or [-1,1]. This effectively avoids the negative impact of excessively large values ​​on homomorphic encryption performance and noise growth. Taking min-max normalization as an example, for the attribute age, if the minimum age (min) is 20 years old and the maximum age (max) is 60 years old in the entire dataset, then for the original age of 35 in the sample, its normalized attribute code is calculated as (35-20) / (60-20) = 0.375. Similarly, the same normalization operation is performed on the income attribute to obtain its corresponding attribute code, such as 0.625 after normalization.

[0032] For identified categorical attributes, such as occupation and city, one-hot encoding will be performed. One-hot encoding transforms unordered categories into high-dimensional binary vectors, thereby eliminating non-existent ordinal relationships between categories and allowing them to be correctly processed by linear models. Taking the occupation attribute as an example, if there are three occupations in the dataset: engineer, teacher, and doctor, the system will create a vector of length 3. For the engineer in the sample, its one-hot encoding is [1,0,0]; if the occupation is teacher, it is encoded as [0,1,0]. Similarly, for the city attribute, if there are three categories: Beijing, Shanghai, and Guangzhou, the Beijing in the sample will be encoded as [1,0,0].

[0033] After the above processing, the original data sample {"Name":"Zhang San","Age":35,"Income":85000,"Occupation":"Engineer","City":"Beijing"} is converted into an attribute code set. The final attribute code set is [0.375,0.625,1,0,0,1,0,0]. Specifically, the "Name" attribute, since it is usually used as a unique identifier and does not have generalized statistical significance, can be excluded from the attribute code set used for classification calculations and is not included in the attribute code set used for classification calculations in this scheme.

[0034] In step 2, sensitivity labels are assigned to each attribute code in the set of attribute codes based on a sensitivity policy. Then, based on these sensitivity labels, a corresponding homomorphic encryption public key is selected from the client key chain to encrypt each attribute code in the set of attribute codes, resulting in a labeled ciphertext bundle. Correspondingly, after completing the standardized encoding of the original data, the core challenge facing the system is how to effectively protect this data before uploading it to an untrusted cloud environment. As described in the background section, using a single-strength encryption scheme leads to a sharp contradiction between efficiency and cost. Real-world data attributes naturally possess different privacy values ​​and leakage risks; for example, a user's identity information is clearly more sensitive than their interest tags. If the same encryption method is used indiscriminately for all encoded data, either overall performance is sacrificed to protect highly sensitive data, or sufficient security is not provided for highly sensitive data in pursuit of efficiency. Therefore, to achieve the best balance between security, computational efficiency, and access control flexibility, a mechanism capable of identifying and differentiating between data of different sensitivities needs to be introduced to perform differentiated encryption processing on the data.

[0035] In a feasible embodiment of the present application, Step 2 is as described below: First, a clear sensitivity policy needs to be preset. This policy is essentially a mapping rule defined by the data owner or authorized institution, which maps each possible attribute type in the dataset to a predefined sensitivity level. For example, a sensitivity system with three levels of high, medium, and low can be set. A specific sensitivity policy can be defined as: {"ID number": "high", "name": "high", "income": "medium", "age": "medium", "occupation": "low", "city": "low"}. This policy is stored on the client side as the basis for subsequent assignment of sensitivity labels.

[0036] Next, the client program will assign sensitivity labels to each encoded value in the set of attribute encodings generated in the previous step according to this sensitivity policy. Continuing from the output of the previous step, that is, the set of attribute encodings [0.375, 0.625, 1, 0, 0, 1, 0, 0], this set corresponds to the four encoded features of age, income, occupation (engineer), and city (Beijing) in sequence. According to the preset sensitivity policy, the client will generate a corresponding sequence of sensitivity labels for these encoded values. For example, the labels for age and income are medium, while the labels for the encoded values related to occupation and city are both low.

[0037] After the sensitivity labels are assigned, a differential homomorphic encryption process will be executed. The client locally maintains a key chain, which stores multiple pairs of homomorphic encryption public and private keys corresponding to different sensitivity levels. For example, the key chain contains {"high": (public key H, private key H), "medium": (public key M, private key M), "low": (public key L, private key L)}. The client program will traverse the set of attribute encodings and its corresponding sequence of sensitivity labels. For the encoded values 0.375 and 0.625 with the label of medium, the program will call the medium-strength public key M in the key chain for encryption to generate two ciphertexts C_age and C_income. For the categorical attributes with the label of "low", the program will encrypt the vector composed of its one-hot encoding as a whole. Specifically, the one-hot encoding vector [1, 0, 0] representing occupation will be encrypted using the low-strength public key L to generate a ciphertext C_job. Similarly, the one-hot encoding vector [1, 0, 0] representing city will also be encrypted using the public key L to generate another ciphertext C_city.

[0038] Finally, these ciphertexts generated by different public key encryptions, together with their corresponding sensitivity labels, will be organized into a structured data unit, that is, a labeled ciphertext bundle. The logical structure of this ciphertext bundle can be expressed as: [{label: "medium", ciphertext: C_age}, {label: "medium", ciphertext: C_income}, {label: "low", ciphertext: C_job}, {label: "low", ciphertext: C_city}].

[0039] In step 3, the labeled ciphertext bundle and its corresponding public key and relinearization key are uploaded to the cloud to obtain the stored ciphertext bundle and the cloud secret key chain. It should be understood that after the client completes the differential encryption of the data, the core computing tasks need to be executed on the cloud with rich resources. However, as a third-party environment not directly controlled by the data owner, the cloud platform itself does not have the ability to decrypt data and cannot perform meaningful operations on ciphertext out of thin air. Although homomorphic encryption technology allows calculations on ciphertext, these calculations (especially multiplication between ciphertexts) require specific auxiliary key information, and the cloud needs to know which key to use to process which ciphertext. Therefore, in order to enable the cloud to correctly and securely execute subsequent homomorphic feature engineering and classification calculations while strictly adhering to the zero-trust principle (i.e., the cloud does not hold the decryption private key), this application uploads the labeled ciphertext bundle and its corresponding public key and relinearization private key to securely transmit and deploy the data and auxiliary keys required for calculation to the cloud environment.

[0040] In a feasible embodiment of this application, step 3 is as follows: First, the client needs to integrate and package a data packet to be uploaded, which consists of two key parts. The first part is the labeled ciphertext bundle generated in the previous step, which, as the encrypted user data body, carries all the differentially protected information. Continuing with the previous example, the logical structure of this ciphertext bundle is [{label: "medium", ciphertext: C_age}, {label: "medium", ciphertext: C_income}, {label: "low", ciphertext: C_job}, {label: "low", ciphertext: C_city}] The second part is the set of auxiliary keys necessary for performing homomorphic operations on the cloud. This set is carefully constructed and does not contain any private keys that can be used for final decryption, thus ensuring the end-to-end confidentiality of the data.

[0041] This auxiliary key set mainly consists of a public key and a relinearization key. Their generation is completed locally on the client and is closely related to the sensitivity level. Taking medium strength as an example, the client first generates a master private key SK_M, which is a random polynomial with specific norm constraints. Based on this private key SK_M, a corresponding public key PK_M is generated by introducing a random polynomial and a small noise term. This public key PK_M is used to encrypt data but cannot be used for decryption. Next, to support subsequent ciphertext multiplication operations, the client uses the master private key SK_M to generate the corresponding relinearization key RelinKey_M. The relinearization key is essentially an encrypted version of a high power (e.g., SK_M^2) of the master private key SK_M under the public key PK_M; it does not reveal any information about SK_M itself. Its key function is to efficiently transform the resulting ciphertext from a complex form dependent on SK_M^2 back to a standard form dependent only on SK_M after performing multiplication on two ciphertexts in the cloud. This controls the ciphertext size and noise growth, ensuring that multi-step multiplication (i.e., sufficiently deep computational circuitry) can be implemented. Similarly, the client also generates a private key SK_L corresponding to the low sensitivity level, from which the public key PK_L and the relinearization key RelinKey_L are derived. Therefore, the final set of auxiliary keys to be uploaded is {PK_M, PK_L, RelinKey_M, RelinKey_L}.

[0042] Subsequently, the client uploads the encapsulated tagged ciphertext bundle and auxiliary key set to the cloud platform via a secure, authenticated communication channel (e.g., using Transport Layer Security (TLS)). Upon receiving this data, the cloud platform performs categorized storage and management. On one hand, the tagged ciphertext bundle is stored in a distributed secure storage system in the cloud (such as an encrypted database or object storage service), forming a stored ciphertext bundle, and an index is created for efficient subsequent retrieval. On the other hand, the received auxiliary key set is stored in a dedicated key management module, forming a cloud keychain. This cloud keychain is a set containing only public keys and relinearization keys. The cloud system establishes a mapping relationship based on the sensitivity tags in the ciphertext bundle. For example, the system records tags corresponding to the public key PK_M and the relinearization key RelinKey_M, while tags corresponding to PK_L and RelinKey_L.

[0043] In step 4, in response to the received classification request, the cloud platform parses the stored ciphertext bundle based on the cloud key chain to obtain parsed ciphertext vectors and tag vectors. It is understandable that after storing massive amounts of encrypted data, the core value of the cloud platform lies in responding to requests and providing computing services. However, this data exists in an unstructured ciphertext bundle form with metadata, which cannot be directly fed into the computing pipeline. Furthermore, any access to and computation of sensitive data must be authorized and verified to prevent unauthorized access and resource abuse. The cloud computing engine requires a standardized, ordered input format to efficiently execute subsequent homomorphic operations and must explicitly know the security level of each encrypted data fragment to invoke the correct computation strategy and key. Therefore, before formally initiating complex cryptomorphic computation, a parsing process is required to establish a secure and ordered preprocessing flow. This first ensures the legitimacy of the request and then converts the stored, fragmented ciphertext bundle into structured ciphertext vectors that can be directly used for subsequent computations and tag vectors that guide the computation path.

[0044] In one feasible embodiment of this application, Figure 3 This is a flowchart of step 4 in the cloud-based privacy-preserving data classification method according to an embodiment of this application. Figure 3 As shown, step 4, in response to receiving a classification request in the cloud, parses the stored ciphertext bundle based on the cloud key chain to obtain the parsed ciphertext vector and tag vector, including: step 41, in response to receiving a classification request, performing a validity verification on the classification request; step 42, after the validity verification is passed, retrieving the corresponding stored ciphertext bundle from the cloud storage; step 43, parsing the stored ciphertext bundle to obtain the ciphertext and sensitivity tag of each attribute; step 44, arranging the ciphertext of each attribute to obtain the parsed ciphertext vector; step 45, arranging the sensitivity tags of each attribute to obtain the tag vector.

[0045] In the above feasible embodiments, step 4 is as follows: First, step 41 is performed. The cloud service first receives a classification request initiated by an external entity (such as an authorized application or data analyst) through a network interface. This request is not a simple instruction, but a structured data object containing various credential information for legitimacy verification. A typical classification request may be designed to include the following fields: a digital identity token issued by a certification authority (e.g., a JSON Web Token), a unique request ID and timestamp to prevent replay attacks, and a digital signature to verify the integrity of the request. When the cloud ingress controller receives such a request, it initiates a multi-stage legitimacy verification process. First, the controller verifies the validity of the digital signature. It uses a public key pre-registered in the cloud system associated with the request initiator to decrypt and hash the request body, and compares the result with the digital signature attached to the request. If they do not match, it indicates that the request may have been tampered with during transmission, and the verification immediately fails. After the signature verification is successful, the controller then parses the digital identity token. It checks whether the token's issuing authority is a trusted certification authority and verifies the token's validity to ensure it hasn't expired. The token contains the user's identity (UserID) and scope of permissions. The controller extracts this information. Subsequently, the system performs permission verification. It uses the user's identity extracted from the token and the requested task type (i.e., a classification task) to query a pre-configured cloud-based Access Control List (ACL) or Role-Based Access Control (RBAC) policy library. This policy library is pre-configured by the platform administrator, explicitly defining which user or role is authorized to perform what operations on which datasets. For example, the policy library might contain a rule: "Role 'Data Analyst' is authorized to perform the 'Classification' operation on 'Dataset A'." If the user role of the current request matches this, the permission verification passes. Finally, the system also uses the unique ID and timestamp in the request to defend against replay attacks. It queries a log of processed requests to ensure that the request ID appears for the first time. If the ID is duplicated, it is considered malicious replay, and the verification fails. Only after all the above verification steps are successfully completed is the classification request deemed legitimate and granted an internal session credential, allowing it to proceed to the next processing step. If any step fails, the request will be immediately rejected, triggering a security alert and logging.

[0046] After successful legitimacy verification, proceed to step 42. A classification request that has passed legitimacy verification will have its internal session credentials and task parameters passed to the cloud-based data scheduling module. The task parameters of this request contain one or more identifiers used to locate the target data. This identifier can be designed according to different application scenarios; for example, it can be a unique data sample ID, such as `Sample_ID_12345`, a data batch ID, such as `Batch_ID_678`, or a query condition pointing to a specific user dataset. Upon receiving these identifiers, the data scheduling module interacts with the cloud-based metadata management service. The metadata management service maintains a large index table that records the mapping relationship between all encrypted bundles stored in the cloud and their logical identifiers. This index table itself is also strictly protected by access control; only authorized internal services, such as the data scheduling module, can query it. For example, when the request specifies that `Sample_ID_12345` should be processed, the scheduling module will initiate a query to the metadata service. Based on this ID, the metadata service locates the physical storage address or unique key name of the stored ciphertext bundle corresponding to the data sample in a cloud-based distributed storage system, such as an object storage service or a key-value database. After obtaining the storage address or key name, the data scheduling module initiates a read operation to the underlying cloud storage system. The cloud storage system, based on the provided address, locates the corresponding binary data object and retrieves its contents. This retrieved data object is the structured data unit containing encrypted data and sensitivity tags stored in the previous steps—the stored ciphertext bundle.

[0047] Next, step 43 is executed. The parsing module in the cloud receives the ciphertext bundle object passed in from the previous step. Continuing with the example from the previous text, the logical structure of this ciphertext bundle object in memory is a list containing multiple dictionaries or objects, in the form of [{label: "medium", ciphertext: C_age}, {label: "medium", ciphertext: C_income}, {label: "low", ciphertext: C_job}, {label: "low", ciphertext: C_city}]. This ciphertext bundle is essentially a serialized data structure. For example, it may be encoded in JSON, Protocol Buffers, or other binary formats. The parsing module will first deserialize this data structure according to a predefined format, restoring it to a memory object directly accessible by the program. Subsequently, the parser starts a traversal program to iteratively access each element in the list. In the first iteration, the parser accesses the first element {label: "medium", ciphertext: C_age}. It reads the label field of this element to obtain the string "medium"; at the same time, it reads the ciphertext field to obtain the binary ciphertext object C_age representing the encrypted age data. At this point, the parser has successfully extracted the complete information of the first attribute: the ciphertext C_age and its corresponding sensitivity label "medium". Then, the traversal program continues to execute. In the second iteration, it accesses the second element {label: "medium", ciphertext: C_income} and extracts the ciphertext C_income and the label "medium" in the same way. In the third and fourth iterations, it will successively access {label: "low", ciphertext: C_job} and {label: "low", ciphertext: C_city}, and extract the ciphertext C_job and the label "low", as well as the ciphertext C_city and the label "low" respectively. When the traversal is completed, the originally integrated ciphertext bundle is successfully decomposed into four independent attribute units containing complete context information. These parsed, paired (ciphertext, sensitivity label) elements are temporarily stored in an ordered intermediate data structure, waiting to be sent to the next step for arrangement and recombination.

[0048] Finally, to form a standardized format suitable for subsequent matrix operations and model input, the system executes steps 44 and 45. In step 44, all the parsed ciphertexts are arranged in a predetermined order to form an ordered vector, that is, the parsed ciphertext vector. This vector can be represented as [C_age, C_income, C_job, C_city]. In step 45, in exactly the same order, the sensitivity labels corresponding to each ciphertext are arranged to form a label vector, which can be represented as ["medium", "medium", "low", "low"].

[0049] In step 5, based on the label vector, the parsed ciphertext vector is subjected to label-guided homomorphic feature engineering and classification calculation in the cloud to obtain the encryption result, which is then sent to the client. Accordingly, after a series of data preparations, the cloud has obtained structured encrypted data (parsed ciphertext vector) and its corresponding security policy metadata (label vector). At this point, the core challenge of computation lies in how to perform complex machine learning classification tasks without decrypting the data. Traditional classification models often involve nonlinear feature interactions and activation functions, while homomorphic encryption environments impose strict limitations and high overhead on such operations (especially multiplication). Directly applying the most complex computational model to all data would result in significant performance waste, while using an overly simple model might sacrifice prediction accuracy. Therefore, in order to establish an intelligent and adaptive encrypted computing framework, this application requires label-guided homomorphic feature engineering and classification calculation on the parsed ciphertext vector. This allows for the dynamic selection of the optimal calculation strategy using the client's preset sensitivity information, balancing computational complexity and efficiency while meeting different data security level requirements. Ultimately, the entire classification and prediction process is completed on the ciphertext, and the encrypted results that cannot be deciphered in the cloud are securely returned to the data owner.

[0050] In one feasible embodiment of this application, Figure 4 This is a flowchart of step 5 in the cloud-based privacy-preserving data classification method according to an embodiment of this application. Figure 4 As shown, step 5 involves performing label-guided homomorphic feature engineering and classification calculation on the parsed ciphertext vector in the cloud based on the label vector to obtain an encryption result, and then sending the encryption result to the client. This includes: step 51, inputting the label vector into an adaptive encryption model to obtain an activated computation path; step 52, performing homomorphic feature engineering on the parsed ciphertext vector to obtain an encrypted feature vector; step 53, inputting the encrypted feature vector into the activated computation path to obtain the encryption result; and step 54, sending the encryption result to the client.

[0051] In the above feasible embodiments, step 4 is as follows: First, step 51 is executed. The cloud predefines and instantiates an adaptive encryption model. This model is a structured decision module that selects one of multiple pre-set computational paths to perform subsequent classification tasks based on the input label vector. In one feasible embodiment of this application, the computational paths include a standard path and an advanced path, which are only suitable for addition and multiplication operations, ensuring computability within the encryption domain. In one feasible embodiment of this application, the standard path and the advanced path include a linear computation part and a nonlinear activation part, wherein the nonlinear activation part is implemented using a polynomial approximation. Specifically, the standard path corresponds to a classification model with high computational efficiency but potentially low model complexity; for example, it can be an encrypted logistic regression model. The computation process of this model is mainly a one-time homomorphic weighted summation, i.e., Σ(w*x)+b, where w is the model weight, x is the encrypted input feature, and b is the bias term. This path is suitable for handling conventional classification tasks that do not contain the most sensitive data. In contrast, the advanced path corresponds to a classification model with higher computational complexity, capable of handling more complex feature relationships, and providing higher prediction accuracy, such as a cryptographic deep neural network containing multiple layers of nonlinear activation components. Each layer of this network includes a linear computational part (homomorphic weighted summation) and a nonlinear activation part. Since standard activation functions such as ReLU or Sigmoid cannot be directly implemented in homomorphic encryption, this scheme uses low-order polynomials (such as quadratic or cubic polynomials) to approximate these functions, which introduces additional homomorphic multiplication operations, thereby increasing computational depth and complexity. It is worth mentioning that the model architecture, encryption weights, and bias parameters corresponding to these two paths have all been completed in the offline training phase and securely stored in the cloud. When the adaptive encryption model receives the label vector, its internal rule engine is triggered. In one feasible embodiment of this application, step 51, inputting the label vector into the adaptive encryption model to obtain the activated computation path, includes: step 511, in response to the absence of a high-sensitivity label in the label vector, determining the activated computation path as a standard path; step 512, in response to the presence of a high-sensitivity label in the label vector, determining the activated computation path as a high-level path. For example, if the input label vector is ["Medium", "Medium", "Low", "Low"]. The rule engine will traverse each element in this vector, checking for any elements with high values. After traversing all labels, the engine does not find any high-sensitivity labels. According to the preset decision rules, the model will make a decision to determine the activated path of this computation task as the standard path. This decision result, i.e., the identifier of the standard path, will be passed to the subsequent scheduler. Conversely, if the data sample contains attributes such as an ID card number, its corresponding label vector may be ["High", "Medium", "Low", "Low"].When this vector is input into the adaptive encryption model, the rule engine detects its high value upon examining the first element. Based on another preset rule, the engine immediately identifies the activation path as the high-level path.

[0052] Next, step 52 is executed. In one feasible embodiment of this application, step 52, which involves performing homomorphic feature engineering on the parsed ciphertext vector to obtain an encrypted feature vector, includes: step 521, extracting a first ciphertext and a second ciphertext with a sensitivity label of medium sensitivity from the parsed ciphertext vector; step 522, calculating the interaction term between the first ciphertext and the second ciphertext to obtain a first ciphertext-to-homomorphic ciphertext; step 523, performing feature scaling on the first ciphertext-to-homomorphic ciphertext to obtain a second ciphertext-to-homomorphic ciphertext; and step 524, calculating the polynomial feature of the first ciphertext-to-homomorphic ciphertext to obtain a third ciphertext-to-homomorphic ciphertext. First, step 521 is executed. The feature engineering strategy may predefine that features with certain specific sensitivities or specific business meanings are cross-combined. In this embodiment, the strategy specifies that all medium-sensitivity features are processed. Therefore, the module traverses the label vector, identifies the index position of the label, and extracts the corresponding ciphertext from the ciphertext vector. In this example, the first ciphertext C_age and the second ciphertext C_income are successfully extracted. Next, step 522 is executed to calculate the interaction term between the two extracted ciphertexts to capture their potential correlation. In machine learning, feature interactions can reveal combined patterns that cannot be reflected by a single feature; for example, the combination of high age and high income may be a strong predictive signal. This operation is performed through a homomorphic multiplication: C_inter = C_age * C_income. When performing this multiplication, the system needs to call the relinearization key RelinKey_M corresponding to the medium sensitivity level in the cloud keychain. The role of this key is to relinearize the ciphertext, which has increased in size after the multiplication, to restore it to its standard size so that it can participate in subsequent calculations. The result C_inter after the calculation is the first homomorphic ciphertext between the ciphertexts, which encrypts the product of the original age and income. Subsequently, step 523 is executed. Feature scaling is an important technique in machine learning model training, used to normalize feature values ​​of different ranges to a similar scale, which helps to accelerate model convergence and improve stability. This operation is achieved through a homomorphic plaintext-ciphertext multiplication: C_scaled = C_inter * S, where S is a plaintext scaling factor, for example, 0.001. The specific value of this scaling factor is predetermined and stored in the cloud during the offline training phase of the model through statistical analysis of the training dataset (such as calculating the maximum value or standard deviation of the features). The result C_scaled is the second homomorphic ciphertext between ciphertexts, representing the encrypted interaction features after scaling. Furthermore, step 524 is performed to construct multinomial features to capture the nonlinear trends of individual features. For example, the effect of age on the target variable may not be linear, but rather a quadratic or cubic relationship. To capture this trend, the strategy may require calculating the squared term of age. This operation is accomplished through a homomorphic self-multiplication: C_age_sq = C_age * C_age.Similar to the interaction term computation, this multiplication also requires processing using the relinearization key RelinKey_M. The result C_age_sq is the third homomorphic ciphertext between ciphertexts. After all the preset feature engineering operations are completed, the newly generated encrypted features C_inter, C_scaled, and C_age_sq are merged with the original ciphertext vector to form the final encrypted feature vector. For example, the output vector might be [C_age, C_income, C_job, C_city, C_inter, C_scaled, C_age_sq].

[0053] Next, step 53 is executed. The cloud-based computing engine first receives the enhanced encrypted feature vector, for example, [C_age, C_income, C_job, C_city, C_inter, C_scaled, C_age_sq]. Simultaneously, it receives the path activation instruction from step 51. In this example, since the input label vector does not contain high-sensitivity labels, the activated path is the standard path. The standard path in this embodiment is designed as an encrypted logistic regression model. The parameters of this model, namely the weight vector W and the bias term b, are securely stored in the cloud beforehand. These parameters are obtained offline by training a standard logistic regression model on a plaintext dataset compatible with this scheme, and then encoding the resulting weights and bias terms (the bias term b may also be encrypted if homomorphic addition with the ciphertext is required). The dimension of the weight vector W perfectly matches the input encrypted feature vector, for example, W = [W_age, W_income, W_job, W_city, W_inter, W_scaled, W_age_sq]. The calculation process strictly follows the mathematical definition of the logistic regression model, but all operations are performed within the homomorphic encryption domain. First, a homomorphic weighted summation (dot product) is performed. The calculation engine performs a series of plaintext-ciphertext multiplications (weights are plaintext) and ciphertext-ciphertext additions: C_logit = (W_age * C_age) + (W_income * C_income) + ... + (W_age_sq * C_age_sq) + bc, where bc is the encrypted bias term. Each multiplication and addition is an independent homomorphic operation. Finally, the sum of all terms results in a single ciphertext C_logit, which encrypts the linear output value of the logistic regression model. Since the complete output of logistic regression requires a sigmoid activation function, which is non-polynomial and cannot be directly implemented using homomorphic encryption, in the standard path of this embodiment, C_logit can be directly used as the final encrypted result, or a low-order polynomial (such as the first few terms of a Taylor expansion) can be used to approximate the sigmoid function. For example, using f(x)≈0.5+0.25x as an approximation, the final result is Result=0.5+0.25*C_logit. This result Result is a single ciphertext that encrypts a score related to the classification probability. In another scenario, the activated path is a high-level path, for example, because the input contains highly sensitive labels, this path might correspond to a two-layer encrypted neural network. The calculation process will be more complex. The first layer will first perform a homomorphic weighted summation similar to the above to obtain a set of intermediate ciphertext, and then apply a pre-defined polynomial to this set of ciphertext to approximate activation functions such as ReLU or Tanh (for example, using a quadratic polynomial ax^2+bx+c to approximate ReLU).This polynomial activation process introduces homomorphic multiplication, requiring the use of the corresponding relinearization key. The output of the first layer (a new set of ciphertext) serves as the input to the second layer, undergoing homomorphic weighted summation and polynomial activation again. After computation across all layers, a single ciphertext, the encrypted result, is ultimately obtained.

[0054] In particular, performing homomorphic cryptographic computations in the cloud, especially those involving polynomial approximation of nonlinear activation functions, becomes exceptionally complex and resource-sensitive. Such computations not only involve numerous intermediate states and recursive calls but are also prone to frequent anomalies due to numerical instability or resource exhaustion, such as computation timeouts or memory overflows. In traditional multi-process computing environments, the abnormal crash or blocking of one process often triggers a domino effect, impacting or even crippling the entire computing system, leading to service interruptions and resource waste. Especially when processing high-value, privacy-sensitive data, computational stability and reliability are paramount. Therefore, to achieve high robustness and high throughput in complex cryptographic computing environments, this application introduces an independent memory heap private encapsulation localized fault tolerance mechanism. This aims to strictly limit the impact of computational failures to a localized location and achieve rapid, automated fault isolation and recovery, thereby ensuring the continuity and stability of the overall computing service.

[0055] In one feasible embodiment of this application, for each calculation instruction in the linear calculation part and the nonlinear activation part, the calculation process includes:

[0056] First, a computation process is allocated for each computation instruction, and a dedicated memory heap is specified for that process. The specification of the dedicated memory heap includes initializing a process memory block and a process memory control block. The dedicated memory heap is then bound to the scheduler corresponding to that computation process. It should be understood that in a system that concurrently executes a large number of homomorphic computation instructions, there are potential resource contention and interference risks between different computation tasks. A memory leak or abnormal access in one computation instruction may pollute the shared memory space, thereby affecting other normally operating computation tasks and triggering a chain reaction of failures. Therefore, to achieve complete isolation between computation tasks, this application allocates an independent computation process and a dedicated memory heap to each computation instruction and binds the two together. This creates an independent, protected sandbox environment for each computation task, fundamentally eliminating cross-task memory interference. Each process can only operate within its own dedicated memory heap, ensuring the independence and security of computation. Binding the process to the scheduler establishes a clear control chain for subsequent resource management and status monitoring, which is the foundation for achieving localized fault tolerance.

[0057] Next, the computational message parsed from the computational instruction is stored in a private message queue, and the computation is executed in the dedicated memory heap. The computational results, intermediate results, and computational exceptions during the computation process are stored in the dedicated memory heap. Correspondingly, the execution of the computational instruction generates a large amount of intermediate data, final results, and even exception information. If this state information is arbitrarily scattered in the system memory, not only will management be chaotic, but in the event of a fault, the abnormal state may overflow, affecting other parts of the system and making fault location and recovery extremely difficult. Therefore, in order to strictly encapsulate and isolate all state information during the computation process, this application stores the computational instruction in a private queue and forces all computational activities and their products (results, intermediate values, exceptions) to be strictly confined within the dedicated memory heap. This achieves the private encapsulation of the computational state. By enclosing all data related to the computation within the dedicated memory heap, a self-contained computational unit is formed. This greatly enhances the predictability and controllability of the system. When an exception occurs, the fault is naturally confined within the memory heap, preventing pollution of the external environment and creating conditions for subsequent accurate and rapid fault handling.

[0058] Then, in response to an anomaly in the computation process, an anomaly is popped based on the anomaly popped in the computation process. The scheduler suspends the computation process based on the popped anomaly and creates a memory copy of the computation process. The creation of the memory copy includes preserving memory data and resetting the memory heap. It should be understood that traditional anomaly handling methods often attempt to fix the problem in-situ, a complex process with a low success rate, often leading to prolonged process blocking and impacting overall system performance. Especially for complex nonlinear computations, in-situ repair is almost impossible. Therefore, to achieve a fast and efficient fault response, this application adopts the quick-fault principle, that is, instead of attempting to repair the anomaly, it sets up an anomaly popping mechanism so that the scheduler can immediately detect and react. This step establishes an efficient localized fault tolerance and recovery process. Once an anomaly occurs within the computation process (e.g., in a dedicated memory heap), the anomaly information is immediately popped. After the scheduler captures this signal, it immediately suspends the faulty process to prevent it from continuing to consume resources or produce erroneous results. Crucially, it creates a memory copy of the process, which preserves valuable computational data, but simultaneously resets the memory heap state that caused the anomaly. This achieves transient protection of computation, allowing processes to be quickly reconstructed and continue execution in a clean environment based on the preserved data, thereby avoiding long downtime and complex troubleshooting.

[0059] Specifically, the scheduler stores popped exceptions in a discarded memory heap marked in the free memory heap and triggers the discarding of the discarded memory heap asynchronously relative to the computing process. That is, exception information and discarded memory heaps generated during fault handling need to be properly cleaned up to reclaim memory resources. If this cleanup process is synchronized with the main computing flow, each fault handling will pause the computing task, waiting for memory reclamation to complete, which will severely impact the system's computing throughput. Therefore, to decouple the overhead of fault recovery from the main computing flow, this application allows the scheduler to handle these discarded resources asynchronously. This achieves asynchronous and parallel resource reclamation. The scheduler stores popped exception information in a separate memory area marked as discarded and triggers an independent, low-priority reclamation task. The main computing process can then continue execution immediately without waiting for reclamation to complete. This design minimizes the performance impact of fault handling, ensuring that even with frequent local faults, the overall system computing throughput remains at a high level, significantly improving the system's robustness and efficiency.

[0060] Finally, step 54 is executed. The cloud-based response module receives the final encrypted result, `Result`, output from the computation path. This encrypted result is a structured binary data object that encapsulates the ciphertext polynomial coefficients under a homomorphic encryption scheme. Before sending it back to the client, the system first needs to serialize it into a format suitable for network transmission. For example, the ciphertext object can be converted into a Base64-encoded string, or it can be packaged using a more efficient binary serialization protocol such as Protocol Buffers. Simultaneously, to ensure the attribution and integrity of the response, the cloud can attach a digital signature to this serialized encrypted result. The cloud service will sign the response body (containing the serialized encrypted result and some metadata, such as the request ID) using its own private key. After receiving the response, the client can use a pre-obtained cloud service public key to verify the signature, thus confirming that the response indeed comes from a legitimate cloud service and has not been tampered with during transmission. Next, the cloud service will send this packaged response to the client through a pre-established secure communication channel. This channel itself is typically encrypted using Transport Layer Security (TLS), providing basic link-layer protection for data transmission. The cloud server, based on the session information or callback address contained in the initial classification request, sends the response packet to the correct client network endpoint. Upon receiving this response packet, the client application performs a series of receiving and processing operations. First, it verifies the security of the TLS connection. Then, if a digital signature has been attached by the cloud server, the client uses the cloud's public key to verify the signature, ensuring the authenticity and integrity of the response. After successful signature verification, the client parses the response body, extracting the serialized encrypted result string. Finally, the client deserializes this string, restoring it to the homomorphic ciphertext object encrypted result in memory.

[0061] In step 6, the client decrypts and decodes the encrypted result based on its client key chain to obtain the privacy-preserving data classification result. In other words, after the preceding steps, the client has securely received an encrypted computation result from the cloud. Although this result is the final product of the entire complex computation process, it remains encrypted, taking the form of an opaque mathematical object that cannot be directly interpreted. For the user, this encrypted data itself has no business value. The ultimate goal of the computation is to obtain a clear, understandable classification conclusion that can guide decision-making. Therefore, in the final step of completing the entire privacy-preserving data classification task, the client uses its unique decryption key to unlock the encrypted result returned from the cloud, which cannot be accessed by outsiders, and restores it from its underlying numerical representation to a classification label with clear business meaning, thereby transforming the abstract computational product into a final answer that has practical significance for the user.

[0062] In one feasible embodiment of this application, step 6 is as follows: The client application first receives the encrypted result of the homomorphic ciphertext object passed in the previous step, which has been transmitted over the network and deserialized. This ciphertext object securely encapsulates the classification score calculated by the cloud model.

[0063] Next, the client's decryption module is invoked. This module accesses a tightly protected client key chain stored locally on the client. This key chain contains a homomorphic encryption private key `sk` generated in the initial stage (before step 2) that has never left the client. The private key is the core credential for decryption, and its confidentiality is the cornerstone of the entire scheme's security. The decryption module uses this private key `sk` to perform a homomorphic decryption algorithm on the received encrypted ciphertext. The decryption operation is a mathematical process that utilizes the private key and the specific structure of the ciphertext to precisely remove noise and masks introduced during encryption, thereby recovering the original encrypted plaintext value. In this application, the encrypted result is a fraction calculated using an approximate sigmoid function. After the decryption operation, the client receives a plaintext floating-point number, such as 0.75. This value is a direct product of the decryption stage.

[0064] However, a numerical value alone is not the final classification result. Therefore, decryption is immediately followed by the decoding phase. Decoding is the process of mapping the numerical value to specific business meanings. The client will preset a decoding strategy, which corresponds to the target of the cloud-based classification model. A common decoding strategy is a threshold-based binary classification decision. For example, a threshold T can be preset with a value of 0.5. This threshold is determined during the model design and evaluation phase and represents the decision boundary for distinguishing between the two categories.

[0065] The client's decoding logic compares the decrypted value of 0.75 with a threshold of 0.5. Since 0.75 is greater than 0.5, the decoding logic determines that the data sample belongs to the positive class. The specific meaning of this positive class is also predefined; for example, in a credit scenario, it might represent good credit; in medical diagnosis, it might represent high risk. Therefore, the final privacy-preserving data classification result output by the decoding module is a clear, human-readable label, such as "good credit."

[0066] In another instance, if the decrypted value is 0.32, since 0.32 is less than 0.5, the decoding logic will classify it as negative, resulting in an output of "mediocre credit". Through these two closely linked operations of decryption and decoding, the client successfully transforms an opaque encrypted object into a final classification conclusion with clear business value, while ensuring end-to-end data privacy throughout the entire calculation process.

[0067] In summary, the cloud-based privacy-preserving data classification method based on the embodiments of this application is explained, proposing a differentiated encryption and adaptive computation method guided by sensitivity tags. This method first assigns sensitivity tags to different data attributes on the client side according to a preset strategy, and then uses a homomorphic encryption public key matching the tag level for encryption, forming a ciphertext bundle containing ciphertext and tags. This differentiated encryption method avoids the resource waste caused by using the highest strength encryption for all data, initially solving the efficiency problem. Next, in the cloud, the tag vector in the ciphertext bundle is used to guide the subsequent computation process. Through an adaptive encryption model, different computation paths can be dynamically selected to perform homomorphic feature engineering and classification computation based on whether high-sensitivity data exists in the tags. This not only achieves refined and isolated processing of data with different sensitivities, meeting flexible access control requirements, but more importantly, it deeply binds the encryption strategy with the computational logic, achieving a dynamic balance between computational efficiency and security level while ensuring data security. This effectively solves the problems of low efficiency and rigid access control in existing solutions in the background art when processing mixed sensitive data.

[0068] Figure 5 This is a block diagram of a cloud-based privacy-preserving data classification system according to an embodiment of this application. Figure 5 As shown, the cloud-based privacy-preserving data classification system 100 according to an embodiment of this application includes: an attribute encoding module 110, used to encode each attribute in the original data to obtain a set of attribute codes; an attribute encryption module 120, used to assign sensitivity labels to each attribute code in the set of attribute codes based on a sensitivity policy, and to select a corresponding homomorphic encryption public key from the client key chain based on the sensitivity labels to encrypt each attribute code in the set of attribute codes to obtain a tagged ciphertext bundle; and a data uploading module 130, used to upload the tagged ciphertext bundle and its corresponding public key and re-linearity. The encryption key is uploaded to the cloud to obtain a stored ciphertext bundle and a cloud key chain; the parsing module 140 is used to respond to a classification request received in the cloud and parse the stored ciphertext bundle based on the cloud key chain to obtain a parsed ciphertext vector and a tag vector; the encryption module 150 is used to perform tag-guided homomorphic feature engineering and classification calculation on the parsed ciphertext vector based on the tag vector in the cloud to obtain an encryption result, and send the encryption result to the client; the decryption module 160 is used by the client to decrypt and decode the encryption result based on the client key chain to obtain a privacy-protected data classification result.

[0069] As described above, the cloud-based privacy-preserving data classification system 100 according to the embodiments of this application can be implemented in various wireless terminals, such as servers with cloud-based privacy-preserving data classification algorithms. In one possible implementation, the cloud-based privacy-preserving data classification system 100 according to the embodiments of this application can be integrated into the wireless terminal as a software module and / or hardware module. For example, the cloud-based privacy-preserving data classification system 100 can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the cloud-based privacy-preserving data classification system 100 can also be one of many hardware modules of the wireless terminal.

[0070] Alternatively, in another example, the cloud-based privacy-preserving data classification system 100 and the wireless terminal can also be separate devices, and the cloud-based privacy-preserving data classification system 100 can be connected to the wireless terminal via wired and / or wireless networks, and transmit interactive information in accordance with an agreed data format.

[0071] Here, those skilled in the art will understand that the specific operations of each step in the aforementioned cloud-based privacy-preserving data classification system have been referenced above. Figures 1 to 4 The description of the cloud-based privacy-preserving data classification method is detailed here, and therefore, its repeated description will be omitted.

Claims

1. A privacy-preserving data classification method based on a cloud platform, characterized in that, include: Encode each attribute in the original data to obtain a set of attribute codes; Based on a sensitivity strategy, a sensitivity label is assigned to each attribute code in the set of attribute codes, and based on the sensitivity label, a corresponding homomorphic encryption public key is selected from the client key chain to encrypt each attribute code in the set of attribute codes to obtain a labeled ciphertext bundle. The tagged ciphertext bundle and its corresponding public key and relinearization key are uploaded to the cloud to obtain the stored ciphertext bundle and cloud key chain; In response to a classification request received in the cloud, the stored ciphertext bundle is parsed based on the cloud key chain to obtain the parsed ciphertext vector and tag vector. Based on the label vector, the parsed ciphertext vector is subjected to label-guided homomorphic feature engineering and classification calculation in the cloud to obtain the encryption result, and the encryption result is sent to the client. The client decrypts and decodes the encrypted result based on the client key chain to obtain the privacy-protected data classification result.

2. The privacy-preserving data classification method based on a cloud platform according to claim 1, characterized in that, Encode each attribute in the original data to obtain a set of attribute codes, including: If the attribute is a numerical attribute, the attribute is normalized to obtain the attribute code; If the attribute is categorical data, perform one-hot encoding on the attribute to obtain the attribute code.

3. The privacy-preserving data classification method based on a cloud platform according to claim 2, characterized in that, In response to a received classification request in the cloud, the stored ciphertext bundle is parsed based on the cloud keychain to obtain a parsed ciphertext vector and a tag vector, including: In response to receiving a classification request, the validity of the classification request is verified; After the legitimacy verification is passed, the corresponding stored ciphertext bundle is retrieved from the cloud storage; The stored ciphertext bundle is parsed to obtain the ciphertext and sensitivity label for each attribute; The ciphertext of each attribute is arranged to obtain the parsed ciphertext vector; The sensitivity labels for each attribute are arranged to obtain the label vector.

4. The privacy-preserving data classification method based on a cloud platform according to claim 3, characterized in that, In the cloud, based on the label vector, label-guided homomorphic feature engineering and classification calculation are performed on the parsed ciphertext vector to obtain an encryption result, and the encryption result is sent to the client, including: The label vector is input into the adaptive encryption model to obtain the activated computation path; Homomorphic feature engineering is performed on the parsed ciphertext vector to obtain an encrypted feature vector; The encryption feature vector is input into the activated computation path to obtain the encryption result; The encrypted result is sent to the client.

5. The privacy-preserving data classification method based on a cloud platform according to claim 4, characterized in that, The computation path includes a standard path and an advanced path, which are only suitable for addition and multiplication operations.

6. The privacy-preserving data classification method based on a cloud platform according to claim 4, characterized in that, The label vector is input into the adaptive encryption model to obtain the activated computation path, including: If no highly sensitive label is found in the label vector, the activated computation path is determined to be a standard path. If a highly sensitive label is found in the label vector, the activated computation path is determined to be a high-level path.

7. The privacy-preserving data classification method based on a cloud platform according to claim 4, characterized in that, Homomorphic feature engineering is performed on the parsed ciphertext vector to obtain an encrypted feature vector, including: Extract the first and second ciphertexts with a sensitivity label of medium from the parsed ciphertext vector; Calculate the interaction terms between the first ciphertext and the second ciphertext to obtain the homomorphic ciphertext between the first ciphertexts; The first homomorphic ciphertext between ciphertexts is feature-scaled to obtain the second homomorphic ciphertext between ciphertexts. Calculate the polynomial features of the first homomorphic ciphertext to obtain the third homomorphic ciphertext.

8. The privacy-preserving data classification method based on a cloud platform according to claim 5, characterized in that, The standard path and the advanced path include a linear computation part and a nonlinear activation part, wherein the nonlinear activation part is implemented using a polynomial approximation.

9. A privacy-preserving data classification system based on a cloud platform, characterized in that, include: The attribute encoding module is used to encode each attribute in the original data to obtain a set of attribute codes; The attribute encryption module is used to assign sensitivity tags to each attribute code in the set of attribute codes based on a sensitivity policy, and to select a corresponding homomorphic encryption public key from the client key chain based on the sensitivity tags to encrypt each attribute code in the set of attribute codes to obtain a tagged ciphertext bundle. The data upload module is used to upload the tagged ciphertext bundle and its corresponding public key and relinearization key to the cloud to obtain the stored ciphertext bundle and cloud key chain; The parsing module is used to respond to a classification request received in the cloud by parsing the stored ciphertext bundle based on the cloud key chain to obtain the parsed ciphertext vector and tag vector. An encryption module is used to perform label-guided homomorphic feature engineering and classification calculation on the parsed ciphertext vector based on the label vector in the cloud to obtain an encryption result, and send the encryption result to the client; The decryption module is used by the client to decrypt and decode the encrypted result based on the client's key chain to obtain the privacy-protected data classification result.

Images