CN117972752A

CN117972752A - Data management method of secret database and related equipment

Info

Publication number: CN117972752A
Application number: CN202410200887.2A
Authority: CN
Inventors: 梁召远; 李阳; 吴晓晨; 徐岩
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2024-02-22
Filing date: 2024-02-22
Publication date: 2024-05-03

Abstract

The specification provides a data management method of a secret database and related equipment. The method comprises the following steps: acquiring a table establishment statement for establishing a target data table in a secret state database; determining whether the target data table contains a data column for storing homomorphic encrypted data; if the data column for storing the full homomorphic encryption data is included, creating the target data table in the secret state database, and creating an affiliated table corresponding to the target data table; wherein the data column included in the target data table is used for storing indication information indicating that the data column does not store the fully homomorphic encryption data any more; the auxiliary table is used for storing ciphertext compression data blocks, and the ciphertext compression data blocks comprise a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data.

Description

Data management method of secret database and related equipment

Technical Field

One or more embodiments of the present disclosure relate to the field of database technologies, and in particular, to a method and related device for managing data of a secret database.

Background

The encrypted database is a database management system for storing and managing ciphertext data (or encrypted data), the data is stored in the database in an encrypted form, and the calculation, the search and the like of the data are completed in the encrypted form, so that the data security can be better maintained.

However, since the encrypted data is stored in the encrypted database, most encryption algorithms, such as the full homomorphic encryption (Fully Homomorphic Encryption, FHE) algorithm, destroy the original features of the plaintext data, including sequential features, association features, and meta information of data types, and also cause serious expansion of data space, the expansion rate may even reach hundreds of thousands times, and further greatly increase the storage cost and communication cost of the ciphertext data, and seriously affect the retrieval and calculation efficiency of the data.

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a data management method for a secret database and related devices.

In a first aspect, the present specification provides a method for data management of a secret database, the method comprising:

Acquiring a table establishment statement for establishing a target data table in a secret state database;

determining whether the target data table contains a data column for storing homomorphic encrypted data;

If the data column for storing the full homomorphic encryption data is included, creating the target data table in the secret state database, and creating an affiliated table corresponding to the target data table; wherein the data column included in the target data table is used for storing indication information indicating that the data column does not store the fully homomorphic encryption data any more; the auxiliary table is used for storing ciphertext compression data blocks, and the ciphertext compression data blocks comprise a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data.

In a second aspect, the present specification provides a data management apparatus for a secret database, the apparatus comprising:

the acquisition unit is used for acquiring a table establishment statement used for establishing a target data table in the secret state database;

a determining unit configured to determine whether the target data table contains a data column for storing fully homomorphic encrypted data;

a table creating unit configured to create the target data table in the secret database if a data column for storing the isomorphic encrypted data is included, and create an attached table corresponding to the target data table; wherein the data column included in the target data table is used for storing indication information indicating that the data column does not store the fully homomorphic encryption data any more; the auxiliary table is used for storing ciphertext compression data blocks, and the ciphertext compression data blocks comprise a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data.

Accordingly, the present specification also provides a computer apparatus comprising: a memory and a processor; the memory has stored thereon computer programs/instructions executable by the processor; the processor, when executing the computer program/instructions, performs the method for managing data of a secret database according to the first aspect.

Accordingly, the present specification also provides a computer readable storage medium having stored thereon a computer program/instruction which, when executed by a processor, performs a method of data management of a cryptographic database as described in the first aspect above.

Accordingly, the present specification also provides a computer program product comprising computer programs/instructions which, when executed by a processor, perform the method of data management of a cryptographic database as described in the first aspect above.

In summary, the present application obtains a table-building statement for creating a target data table in a secret database, and then determines whether the target data table contains a data column for storing the isomorphic encrypted data. If the target data table contains a data column for storing the full homomorphic encryption data, the target data table is created in the secret database, and an affiliated table corresponding to the target data table is created. Wherein the data column contained in the target data table is no longer used to store fully homomorphic encrypted data, but is used to store indication information indicating that the data column is no longer storing fully homomorphic encrypted data. The auxiliary table is used for storing a ciphertext compression data block, and the ciphertext compression data block comprises a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data. On one hand, the method compresses the original fully-homomorphic encryption data to be stored through the fully-homomorphic encryption compression algorithm, and only the ciphertext compression data block obtained after compression is actually needed to be stored, so that the ciphertext expansion rate is greatly reduced, and the data query efficiency is improved. On the other hand, the application creates a corresponding auxiliary table for the data table originally used for storing the full homomorphic encryption data, any encryption data is not needed to be stored in the subsequent original table, and the ciphertext compression data block obtained after compression can be stored through the auxiliary table, so that the management and the query of the data are facilitated.

Drawings

FIG. 1 is a schematic diagram of a data management system architecture of a cryptographic database according to an exemplary embodiment;

FIG. 2 is a flow chart of a method for data management of a cryptographic database according to an exemplary embodiment;

FIG. 3 is a schematic diagram of the result of an isomorphic encryption compression provided by an exemplary embodiment;

FIG. 4 is an effect diagram of a data import method according to an exemplary embodiment;

FIG. 5 is a schematic diagram of a base table and an attached table provided by an exemplary embodiment;

FIG. 6 is a schematic diagram illustrating the decryption and decompression of ciphertext query results according to an exemplary embodiment;

FIG. 7 is a schematic diagram of a method for ciphertext calculation according to an exemplary embodiment;

FIG. 8 is a schematic diagram of a data management device of a secret database according to an exemplary embodiment;

fig. 9 is a schematic diagram of a computer device according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with aspects of one or more embodiments of the present description as detailed in the accompanying claims.

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments.

The term "plurality" as used herein means two or more.

In addition, the user information (including but not limited to user equipment information, user personal information, etc.) and the data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data are required to comply with the related laws and regulations and standards of the related country and region, and are provided with corresponding operation entries for the user to select authorization or rejection.

First, some terms in the present specification are explained for easy understanding by those skilled in the art.

(1) The encrypted database (ENCRYPTED DATABASE) is a database management system for storing and managing ciphertext data (or encrypted data), the data is stored in the database in an encrypted form, the calculation, the search and the like of the data are completed in the encrypted form, and the grammar analysis, the transaction ACID and other capabilities related to the database management are integrated with the traditional database capabilities. The secret database is the product of the deep combination of a database system and encryption technology and mathematical algorithm. The core task of the secret state database is to protect the safety of the whole life cycle of the data and support the retrieval and calculation of the ciphertext data.

However, since the encrypted form of data is stored in the encrypted form database, most encryption algorithms, such as the full homomorphic encryption (Fully Homomorphic Encryption, FHE) algorithm, destroy the original features of the plaintext data, including the sequence features, the association features, and the meta information of the data types, so that the data addition operation, the multiplication operation, the comparison operation, and the clustering operation become extremely difficult. Most importantly, serious data space expansion is caused after data encryption, a full homomorphic encryption algorithm generally needs to use a larger key, a longer ciphertext and a more complex algorithm to support wider calculation requirements, and in addition, auxiliary information such as noise data or masks and the like needs to be introduced in the ciphertext calculation process to protect the safety and reliability of the encryption algorithm, so that the data expansion rate of the encryption algorithm can even reach hundreds of thousands times, further, the storage cost and the communication cost of ciphertext data are greatly increased, and the retrieval and calculation efficiency of the data are seriously affected.

Based on the above, the present specification provides a technical solution, firstly, creating a corresponding auxiliary table for a data table originally used for storing fully homomorphic encrypted data, then compressing the fully homomorphic encrypted data originally to be stored by a fully homomorphic encryption compression algorithm, and only storing a ciphertext compression data block obtained after compression in the auxiliary table, thereby greatly reducing the ciphertext expansion rate.

In practice, the present application first obtains a build statement for creating a target data table in a dense state database and then determines whether the target data table contains a data column for storing fully homomorphic encrypted data. If the target data table contains a data column for storing the full homomorphic encryption data, the target data table is created in the secret database, and an affiliated table corresponding to the target data table is created. Wherein the data column contained in the target data table is no longer used to store fully homomorphic encrypted data, but is used to store indication information indicating that the data column is no longer storing fully homomorphic encrypted data. The auxiliary table is used for storing a ciphertext compression data block, and the ciphertext compression data block comprises a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data.

In the technical scheme, on one hand, the fully homomorphic encryption compression algorithm is adopted to compress the fully homomorphic encryption data to be stored originally, and only the ciphertext compression data block obtained after compression is actually needed to be stored, so that the ciphertext expansion rate is greatly reduced, and the data query efficiency is improved. On the other hand, the application creates a corresponding auxiliary table for the data table originally used for storing the full homomorphic encryption data, any encryption data is not needed to be stored in the subsequent original table, and the ciphertext compression data block obtained after compression can be stored through the auxiliary table, so that the management and the query of the data are facilitated.

Referring to fig. 1, fig. 1 is a schematic diagram of a data management system architecture of a secret database according to an exemplary embodiment. One or more embodiments provided herein may be embodied in the system architecture shown in fig. 1 or a similar system architecture. As shown in fig. 1, the data processing system may include a computer device 100 and a computer device 200. Wherein computer device 100 and computer device 200 may communicate by any possible means. By way of example, the computer device 100 and the computer device 200 may communicate by wireless communication means such as bluetooth, wi-Fi, or mobile network, or by wired communication means such as data line, etc., which is not particularly limited in this specification.

In an embodiment, the computer device 100 may be used as a client device of the secret database, where a client corresponding to the secret database is installed, and the client may provide various services based on the secret database, such as a data encryption and decryption service, a data compression and decompression service, a ciphertext data query and calculation service, and so on, which are not limited in this specification.

In an embodiment, the computer device 200 may be used as a server device of the secret database, where a server corresponding to the secret database is installed, and the server may provide various services based on the secret database to the user, such as storage, management, query and calculation of ciphertext data, and the like, which is not limited in this specification. The server side of the cryptographic database may include a computing engine and a storage engine, where the computing engine may perform queries and computations related to ciphertext data, the storage engine may perform storage related to ciphertext data, and so on, and the details thereof are not described herein.

In an embodiment, when the storage engine in the server performs ciphertext data storage, a corresponding data table can be created in the ciphertext database first, so that ciphertext data can be better managed, and convenience is provided for inquiring and calculating subsequent ciphertext data. In an embodiment, the ciphertext data may be fully homomorphic encrypted data, and the scheme of the present application will be described in the following examples by taking fully homomorphic encrypted data as an example.

In an illustrated embodiment, the server may obtain a user-entered build statement that may be used to create a target data table in the closed database. Further, the server needs to determine whether the target data table to be created in the table creating statement includes a data column for storing the fully homomorphic encrypted data.

In an illustrated embodiment, when determining whether the target data table to be created includes a data column for storing the full homomorphic encrypted data, the server may specifically include: analyzing the table establishing statement to obtain table establishing information aiming at a target data table to be established, wherein the table establishing information is contained in the table establishing statement; further, the server may determine whether the tabulated information includes a data column, such as an FHE encrypted data column, for storing the fully homomorphic encrypted data.

In an illustrated embodiment, if the table-building statement does not include a data column for storing the fully homomorphic encrypted data, that is, the target data table created this time does not include a data column for storing the fully homomorphic encrypted data, the target data table may be created in the secret database directly according to the table-building information in the table-building statement.

Illustratively, the build statement that does not contain a full homomorphic encrypted data column may be as follows, where the price column may be the encrypted column:

CREATE TABLE test.test_table(

id int,

price double

)ENGINE＝InnoDB DEFAULT CHARSET＝utf8mb4；

In an embodiment, if the table-building statement includes a data column for storing the isomorphic encrypted data, that is, the target data table created this time includes a data column for storing the isomorphic encrypted data, the target data table may be created in the secret database, and an auxiliary table corresponding to the target data table may be created. Accordingly, the original target data table to be created can be regarded as a base table based on the additional created attached table.

The data column (e.g., data_fhe column) for storing the fully homomorphic encrypted data included in the target data table may not store the fully homomorphic encrypted data any more, but may store indication information indicating that the data column does not store the fully homomorphic encrypted data any more, for example, a preset string "NULL" indicating NULL data. Meanwhile, an attached table corresponding to the target data table may be used to store the compressed isohomomorphic encrypted data. In an embodiment, the attached table may specifically store a plurality of ciphertext compressed data blocks corresponding to different compressed block identifiers (or compressed block serial numbers), where each ciphertext compressed data block may include a plurality of ciphertext compressed data obtained by compressing a plurality of fully homomorphic encrypted data to be written, so as to greatly reduce a ciphertext expansion rate. By way of example, the present application may compress and fully homomorphic encrypt a plurality of plaintext data by using a fully homomorphic encryption compression algorithm, thereby obtaining the ciphertext compressed data block, and the description of the corresponding embodiment of fig. 3 will be specifically referred to below, which is not described in detail herein.

Illustratively, the build statement containing a full homomorphic encrypted data column may be as follows, where the price column may be the encrypted column:

CREATE TABLE test.test_table(

id int,

price double encrypted with(type＝fhe)

)ENGINE＝InnoDB DEFAULT CHARSET＝utf8mb4；

in an embodiment, the table name of the attached table corresponding to the target data table may be named fhe _lob_ $ { original table name }, where the original table name is the table name of the target data table.

In an illustrated embodiment, the attachment table may include a compressed block identification column (e.g., FHE_REF column) for storing compressed block identifications of ciphertext compressed data blocks. Wherein the FHE_REF column is a self-increment column. Accordingly, after the attached table is created, the compressed block identification column (i.e., FHE_REF column) may be synchronously added to the target data table. And, the compressed block identifier stored in the compressed block identifier column of the target data table corresponds to the compressed block identifier stored in the compressed block identifier column of the affiliated table, thereby establishing an association relationship between the target data table and the affiliated table.

In one illustrated embodiment, the attachment table may also include compressed data columns for storing the data content of the ciphertext compressed data blocks. The compressed data column may be named $ { primary column name } -FHE, for example, the data_fhe column originally used for storing the fully homomorphic encrypted data in the primary table, which is not specifically limited in this specification.

Further, after the target data table and the corresponding auxiliary table are created, the encrypted state database can receive the ciphertext compressed data uploaded by the user through the client running on the computer device 100, and store and manage the ciphertext compressed data; and, in response to a request initiated by the client, performing a query and calculation of the corresponding ciphertext compressed data, and so on.

In an illustrated embodiment, the server may obtain a target ciphertext compressed data block sent by the client, and determine a target compressed block identifier corresponding to the target ciphertext compressed data block; the target ciphertext compressed data block includes N ciphertext compressed data obtained by compressing and fully homomorphic encrypting N plaintext data, where N is an integer greater than or equal to 1, for example 8192.

Further, the server may write the target compressed block identifier into the compressed block identifier column of the auxiliary table, and write the target ciphertext compressed data block into the data row where the target compressed block identifier is located in the compressed data column of the auxiliary table.

Further, the server synchronously writes the target compressed block identifier into N data rows corresponding to the target ciphertext compressed data block in the compressed block identifier column of the target data table, and so on, which will be specifically described with reference to the following corresponding embodiment of fig. 4, and will not be described in detail herein.

Therefore, the method and the device realize that only the ciphertext compressed data block obtained after compression is stored in the additionally created auxiliary table by compressing the original isomorphic encrypted data to be stored, thereby greatly reducing the ciphertext expansion rate and improving the data query efficiency.

In an illustrated embodiment, the computer device 100 may be a smart wearable device, a smart phone, a tablet computer, a notebook computer, a desktop computer, etc. having the above functions, which is not particularly limited in this specification.

In an embodiment, the computer device 200 may be a desktop computer, a server, or a server cluster including a plurality of servers, etc. with the functions described above, which are not specifically limited in this specification.

It should be understood that fig. 1 is only illustrative, and in some possible embodiments, a data management system of a secret database may further include more or less structures than those shown in fig. 1, which are not specifically limited in this specification.

Referring to fig. 2, fig. 2 is a flowchart of a data management method of a secret database according to an exemplary embodiment. The method can be applied to the data management system of the secret database shown in fig. 1. As shown in fig. 2, the method may specifically include the following steps S201 to S203.

Step S201, a table creating statement for creating a target data table in a secret database is obtained.

In an illustrated embodiment, a server of the cryptographic database may obtain a user-entered table-building statement that may be used to create a target data table in the cryptographic database. In an illustrated embodiment, the build statement may be a build statement based on a structured query language (Structured Query Language, SQL), which is not specifically limited in this specification.

Step S202, determining whether the target data table contains a data column for storing the homomorphic encrypted data.

Further, the server may determine whether the target data table to be created in the table creating statement includes a data column for storing the full homomorphic encrypted data, for example, an FHE encrypted data column, and the description of the corresponding embodiment of fig. 1 is omitted here.

Step S203, if the data column for storing the full homomorphic encryption data is included, creating the target data table in the secret database, and creating an auxiliary table corresponding to the target data table; wherein the data column included in the target data table is used for storing indication information indicating that the data column does not store the fully homomorphic encryption data any more; the auxiliary table is used for storing ciphertext compression data blocks, and the ciphertext compression data blocks comprise a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data.

In an illustrated embodiment, if the target data table to be created includes a data column for storing the full homomorphic encrypted data, the target data table may be created in the secret database, and an attached table corresponding to the target data table may be created.

The data column (e.g., data_fhe column) for storing the fully homomorphic encrypted data included in the target data table may not store the fully homomorphic encrypted data any more, but may store indication information indicating that the data column does not store the fully homomorphic encrypted data any more, for example, a preset string "NULL" indicating NULL data.

Wherein an attached table corresponding to the target data table may be used to store a plurality of ciphertext compressed data blocks corresponding to different compressed block identifiers. Wherein each ciphertext compressed data block may include: and compressing the plurality of plaintext data and the plurality of ciphertext compressed data obtained by the homomorphic encryption through the homomorphic encryption compression algorithm.

In an embodiment, the auxiliary table may specifically include a compressed block identifier column (e.g. fhe_ref column) and a compressed data column (e.g. data_fhe column), which are specifically described with reference to the corresponding embodiment of fig. 1, and will not be described herein.

It should be noted that, in the fully homomorphic encryption compression algorithm, the ciphertext compression data block (i.e., the FHE compression block) may include a plurality of slots corresponding to a plurality of slot identifiers (index), and correspondingly, a plurality of ciphertext compression data included in the ciphertext compression data block may be respectively located on a plurality of slots corresponding to the plurality of slot identifiers.

Correspondingly, the created target data table can also comprise a slot identification column for storing the slot identification.

The number of compression slots used in the isomorphic encryption compression algorithm is not particularly limited. For example, the number of the slots may be 8192, that is, the present application may divide a plurality of rows of plaintext data into at least one group according to 8192 rows, then encrypt and compress each group of plaintext data by using an isomorphic encryption compression algorithm, thereby obtaining ciphertext-compressed data blocks corresponding to each group of data, and so on.

In the following, an implementation manner of encrypting and compressing plaintext data by using an homomorphic encryption compression algorithm to obtain a ciphertext-compressed data block will be described.

First, in an illustrated embodiment, a client of the cryptographic database may receive a plaintext file uploaded by a user, where the plaintext file may include user information of the user. Specifically, the plaintext file may be a plaintext csv (Comma-separated value) file, or may be any other type of file, which is not specifically limited in this specification.

Further, the client divides a plurality of rows of plaintext data contained in the plaintext csv file according to a rule of 1 group per 8192 rows to obtain a plurality of groups of data. Referring to fig. 3, fig. 3 is a schematic diagram illustrating a result of isomorphic encryption compression according to an exemplary embodiment. As shown in fig. 3, the plaintext csv file contains 8194 rows of data, each row of data may include the data content of the id field and the data field, and the data content of the data field is plaintext. Further, the client divides the 8194 rows of plaintext data into two groups according to a rule of 1 group per 8192 rows, wherein the first group contains 8192 rows of plaintext data with ids of 1-8192, respectively, and the other group contains 2 rows of plaintext data with ids of 8193 and 9184. It should be understood that, in the case where the number of rows of the plaintext data included in the plaintext csv file is divisible by 8192, the number of rows of each group of plaintext data obtained by division is 8192, but in the case where the number of rows of the plaintext data included in the plaintext file is not divisible by 8192, the number of rows of a group of plaintext data is always smaller than 8192, which does not affect the subsequent encryption compression.

Further, as shown in fig. 3, the client may perform encryption compression on each group of plaintext data by using an isomorphic encryption compression algorithm, so as to obtain ciphertext-compressed data blocks corresponding to each group of plaintext data, and generate a corresponding ciphertext csv file. As shown in fig. 3, the ciphertext csv file also contains 2 groups of data of 8194 rows, and each row of data may include the data content of the id field and the data field. As shown in fig. 3, the ciphertext compressed DATA block corresponding to each group of plaintext DATA may be stored in a first row of each group of DATA in the ciphertext csv file, and the remaining rows may be written with a "_fhe_slot_data_null_" string to indicate that the row of DATA is empty.

Further, after the client obtains the ciphertext csv file through the homomorphic encryption compression algorithm, the ciphertext csv file can be sent to the client, and a data import request/instruction is initiated to the server, so that the data content contained in the ciphertext csv file is stored in a corresponding data table.

For example, the server may receive the ciphertext csv file, and group the multiple lines of DATA included in the ciphertext csv file according to the compressed block and the "_fhe_slot_data_null_" string, and process each line of DATA in each group line by line.

Specifically, referring to fig. 4, fig. 4 is a schematic diagram illustrating an effect of a data importing method according to an exemplary embodiment. As shown in fig. 4, for each line of data in the ciphertext csv file, it is first determined whether the data is a ciphertext-compressed data block (i.e., whether it is line 1 data of each group).

In one illustrated embodiment, if the currently processed data is a ciphertext compressed data block (e.g., row 1 data in the first group as shown in fig. 4), the ciphertext compressed data block is written into the data_fhe column (or data_fhe field) of the attachment table, and the compressed block identification of the ciphertext compressed data block is written into the fhe_ref column of the FHE attachment table (e.g., row 1 as shown in fig. 4). In one embodiment, the FHE_REF column may be a self-increment column, such that the contents of the FHE_REF column may be self-incremented to 1 after the ciphertext compressed data block is written into the data_FHE column. Accordingly, NULL may be written in the data_fhe column of the FHE base table and SLOT identification 0 (representing row 1 data of each group, located at SLOT 1 in the compressed block) may be written in the ref_slot_index column, and the contents of the fhe_ref column of the attached table (e.g., 1 as shown in fig. 4) may be backfilled into the fhe_ref column of the base table, i.e., the same compressed block identification may also be written in the fhe_ref column of the FHE attached table.

In one illustrated embodiment, if the currently processed data is not ciphertext compressed block data (i.e., lines 2-8191 of each group), then no data write operation is required to the secondary table, NULL is written directly in the data_fhe column of the primary table, the corresponding SLOT identification (1-8191) is written in the ref_slot_index column, and the contents of the fhe_ref column of the secondary table (e.g., 1 of fig. 4) are backfilled into the fhe_column of the primary table, i.e., the same compressed block identification is written in lines 2-8191 of the fhe_ref column of the secondary table.

And the like, until each line of data in the plurality of groups of data contained in the ciphertext csv file is processed. Referring to fig. 5 for an exemplary illustration, fig. 5 is a schematic diagram of a base table and an attached table according to an exemplary embodiment. After the multiple ciphertext csv files are successfully imported into the base and auxiliary tables, the contents of the base and auxiliary tables may be as shown in FIG. 5. Wherein 8192 rows of data included in the first group of the base table are associated with the first row of data in the auxiliary table (compression block is identified as 1), 8192 rows of data included in the second group of the base table are associated with the second row of data in the auxiliary table (compression block is identified as 2), 1004 rows of data included in the third group of the base table are associated with the third row of data in the auxiliary table (compression block is identified as 3), 2 rows of data included in the fourth group of the base table are associated with the fourth row of data in the auxiliary table (compression block is identified as 4), and so forth, which are not repeated herein. In an embodiment, the base table may further include any other possible data columns such as an id column, a name (name) column, and the like, which is not specifically limited in this specification.

It should be noted that the base table and the auxiliary table shown in fig. 4 and fig. 5 are only exemplary, and in some possible embodiments, the base table and the auxiliary table may include a plurality of data_fhe columns, respectively, and each data_fhe column may be used to store different kinds of data content. For example, the basic table and the auxiliary table may respectively include 2 data_fhe columns, where one data_fhe column is used to store a historical high price H of each product, and the other data_fhe column is used to store a historical low price L of each product, and similarly, the contents in the two data_fhe columns in the basic table are NULL, and the contents in the two data_fhe columns in the auxiliary table are ciphertext compressed data blocks obtained by encrypting and compressing price data.

Further, after the creation of the base table and the auxiliary table and the importing and storing of the ciphertext compression data are completed, the secret database can perform data query, calculation and the like based on the ciphertext compression data stored currently.

In an illustrated embodiment, a client corresponding to the secret database may send a query request to the server, where the query request may include a corresponding query statement. Correspondingly, the server may parse the query statement to obtain the query condition for the data table to be queried included in the query statement. In an illustrated embodiment, the query statement may be an SQL statement.

Further, the server may determine whether the data table to be queried includes a data column for storing the fully homomorphic encrypted data. For example, the server may query metadata related to the data table to be queried in metadata managed by the secret database according to the table name of the data table to be queried, and determine whether the data table to be queried includes a data column for storing the data with the same secret encryption as the data_fhe column according to the content recorded in the metadata.

In an embodiment, if the server determines that the to-be-queried data table includes a data column for storing fully homomorphic encrypted data, the server may further determine an auxiliary table to be queried corresponding to the to-be-queried data table, and obtain a ciphertext compressed data block corresponding to a query condition in a query statement from the auxiliary table to be queried.

In an embodiment, after determining that the data table to be queried includes a data_fhe column, the server may automatically rewrite the query statement, for example, add association information between the data table to be queried and the auxiliary table to be queried in the query statement.

In an embodiment, the server may specifically add the above-mentioned association information by adding a where_cond condition. Illustratively, the where_cond condition may specifically include: where $ { FHE base table }, FHE_REF = $ { FHE auxiliary table }, FHE_REF.

Illustratively, the original query statement sent by the client may be: select from test_ fhe _table; the rewritten query statement may be ：select*from test_fhe_table,fhe_lob_test_fhe_table where test_fhe_table.FHE_REF＝fhe_lob_test_fhe_table.FHE_REF;

Further, after completing the writing of the query statement, the server may execute the written query statement to determine the compressed block identifier corresponding to at least one line of data satisfying the query condition in the data table to be queried, and obtain the ciphertext compressed data block corresponding to the compressed block identifier from the auxiliary table to be queried.

Further, the server may further obtain at least one slot identifier corresponding to the at least one row of data satisfying the query condition from a slot identifier column of the data table to be queried.

Further, the server may send the ciphertext compressed data block and the at least one slot identifier to the client, so that the client decrypts and decompresses the ciphertext compressed data block to obtain a plurality of plaintext data; and determining at least one plaintext data corresponding to the at least one slot identification from the plurality of plaintext data.

For example, the query condition in the query statement may include id equal to 2 to 100, taking the data table to be queried and the auxiliary table to be queried as the basic table and the auxiliary table shown in fig. 4, where the data from 2 nd line to 100 nd line in the data table to be queried satisfy the query condition, and it may be determined that the compressed block identifier corresponding to the data from 2 nd line to 100 nd line is 1, and the slot identifier is 1 to 99.

Further, the server may obtain the ciphertext compressed data block "OxABC12312120401234abcab c12312120401234abcab 12312120401234ABC … …" corresponding to the compressed block identifier 1 from the auxiliary table to be queried, and return the ciphertext compressed data block and the slot identifiers of 1 to 99 to the client. Correspondingly, the client may decrypt and decompress the ciphertext compressed data block to obtain 8192 plaintext data, and determine 99 plaintext data corresponding to the 1 to 99 slot identifiers from the 8192 plaintext data

In an illustrated embodiment, after the query is completed, the server may generate a corresponding ciphertext file based on the ciphertext query result, where the first line of DATA in each set of DATA of the ciphertext file is a ciphertext compressed DATA block, and the remaining lines may all be filled with a "_fhe_slot_data_null" string, so as to reduce the amount of returned DATA.

Referring to fig. 6, fig. 6 is a schematic diagram illustrating an effect of decryption and decompression of a ciphertext query result according to an exemplary embodiment. Taking full table query as an example, a ciphertext file generated by the server based on the ciphertext query result may be as shown in fig. 6, where the ciphertext file may include a name column, a ref_slot_index column, and a data_fhe column, where the first line data of each group in the data_fhe column is ciphertext compression block data. As shown in fig. 6, after receiving the ciphertext file returned by the server, the client may decrypt and decompress the ciphertext file to obtain a piece of data with 8192 SLOTs, and then obtain, according to the value of each row of ref_slot_index, the SLOT INDEX corresponding to each plaintext data, so as to backfill each plaintext data to the corresponding data row, and after completing the processing of all rows, obtain all plaintext data.

In an embodiment, similar to the above-mentioned ciphertext data query flow, in the ciphertext data calculation flow, the server side also analyzes the query statement sent by the client side, determines whether the to-be-queried table in the query statement contains a data column for storing the isomorphic encrypted data, if so, the server side automatically rewrites the query statement, and increases the corresponding sphere_cond condition.

Illustratively, the query statement may be: SELECT DATA +1from test_fhe_table; the rewritten query statement may be ：select_data+1from test_fhe_table,fhe_lob_test_fhe_table where test_fhe_table.FHE_REF＝fhe_lob_test_fhe_table.FHE_REF;

In an illustrated embodiment, in the calculation flow of ciphertext data, the client further performs isomorphic encryption compression on the parameters involved in calculation to generate corresponding ciphertext compression parameter blocks. For example, the client fills the parameter into each slot of the FHE compressed block, taking the query statement "data+1" as an example, the client fills the parameter "1" into 8192 slots, and then performs isomorphic encryption to obtain the corresponding ciphertext compressed parameter block X.

The server side of the encrypted database can execute the rewritten query statement to execute ciphertext calculation based on the queried ciphertext compression data block and the received ciphertext compression parameter block X, so as to obtain a corresponding ciphertext calculation result.

In one illustrated embodiment, the server traverses each row of data in the base table, performing a data+X operation. And, when the server side processes each line of data, a simple bloom filter is maintained. In an illustrated embodiment, the key of the bloom filter may be "REF_SLOT_INDEX" + $ { func_name + $ { FHE-REF }, where func_name is the computation logical name, in the above example item_func_plus (addition), and func_index may be the compressed block identification of the ciphertext compressed data block that participates in the computation. If there is no such key in the current bloom filter, the description is the first computation process of each set of encrypted compressed data, at this time, the key may be added in the bloom filter, and a ciphertext computation is performed, and the ciphertext computation result is returned as the line. If the bloom filter contains the key and the identity of the compressed block corresponding to the func_index contained in the key and the DATA line currently being processed is the same, the DATA group is indicated to be already calculated, and the specific character string "_FHE_SLOT_DATA_NULL_" is returned directly without calculation, so that the DATA group is used for identifying that the DATA line is already calculated.

When the server side executes ciphertext calculation, firstly, ciphertext compression data blocks in the attached table are required to be taken out and used as 1 st parameters participating in ciphertext calculation, then ciphertext compression parameter blocks X sent by the client side are used as 2 nd parameters, and ciphertext addition operation is executed on the 2 nd parameters. Referring to fig. 7, fig. 7 is a schematic diagram illustrating a ciphertext calculation method according to an exemplary embodiment. As shown in fig. 7, the ciphertext calculation follows the calculation principle corresponding to the slot, and the ciphertexts on the corresponding slot are added to obtain the ciphertext calculation result on the slot, so that the +1 operation can be performed on all the ciphertext data in the ciphertext compression data block. It should be understood that fig. 7 is a block diagram illustrating the calculation logic of the ciphertext compression block more intuitively in a plaintext manner, and in the actual ciphertext calculation process, the data in the slot are ciphertext data.

It should be understood that after the server performs the ciphertext calculation, the ciphertext calculation result obtained is still data in an encrypted and compressed state. Further, after the server returns the ciphertext calculation result to the client, the client needs to decrypt and decompress the ciphertext calculation result to obtain a plurality of plaintext data corresponding to a plurality of slots, and then obtains a plaintext calculation result of each row according to a slot identifier corresponding to each plaintext data.

Corresponding to the implementation of the method flow, the embodiment of the specification also provides a data management device of the secret database. Referring to fig. 8, fig. 8 is a schematic diagram of a data management apparatus for a secret database according to an exemplary embodiment, and the apparatus 80 may be applied to the data management system for a secret database shown in fig. 1. As shown in fig. 8, the apparatus 80 includes:

An obtaining unit 801, configured to obtain a table creation statement for creating a target data table in a secret database;

a determining unit 802 for determining whether the target data table contains a data column for storing the homomorphic encrypted data;

A table creating unit 803 for creating the target data table in the secret database and creating an attached table corresponding to the target data table if a data column for storing the homomorphic encrypted data is included; wherein the data column included in the target data table is used for storing indication information indicating that the data column does not store the fully homomorphic encryption data any more; the auxiliary table is used for storing ciphertext compression data blocks, and the ciphertext compression data blocks comprise a plurality of ciphertext compression data obtained by compressing a plurality of to-be-written fully homomorphic encryption data.

In an illustrated embodiment, the attachment table includes a compressed block identification column and a compressed data column; the compressed block identification column is used for storing compressed block identifications corresponding to different ciphertext compressed data blocks respectively, and the compressed data column is used for storing different ciphertext compressed data blocks;

the apparatus 80 further comprises a column adding unit 804 for:

after the auxiliary table is created, synchronously and newly adding the compressed block identification column in the target data table; the compressed block identifiers stored in the compressed block identifier column of the target data table correspond to the compressed block identifiers stored in the compressed block identifier column of the auxiliary table.

In an illustrated embodiment, the apparatus 80 further comprises a first data writing unit 805 for:

Acquiring a target ciphertext compressed data block sent by a client corresponding to the encrypted database, and determining a target compressed block identifier corresponding to the target ciphertext compressed data block; the target ciphertext compressed data block comprises N ciphertext compressed data obtained by compressing N isomorphic encrypted data;

Writing the target compressed block identifier into the compressed block identifier column of the auxiliary table, and writing the target ciphertext compressed data block into a data row where the target compressed block identifier is located in the compressed data column of the auxiliary table; and

And writing the target compressed block identifier into N data rows corresponding to the target ciphertext compressed data block in the compressed block identifier column of the target data table.

In an embodiment, the ciphertext compressed data block includes a plurality of slots corresponding to the plurality of slot identifiers, and the plurality of ciphertext compressed data included in the ciphertext compressed data block are respectively located on the plurality of slots corresponding to the plurality of slot identifiers; the target data table further comprises a slot identification column for storing the slot identification.

In an illustrated embodiment, the apparatus 80 further comprises a second data writing unit 806 for:

N slot identifiers respectively corresponding to the N ciphertext compressed data contained in the target ciphertext compressed data block are determined;

and writing the N slot identifications into N data rows corresponding to the target ciphertext compressed data block in the slot identification column of the target data table respectively.

In an illustrated embodiment, the apparatus 80 further comprises a data querying unit 807 for:

acquiring a query statement sent by a client, and analyzing and obtaining query conditions for a data table to be queried contained in the query statement;

determining whether the data table to be queried contains a data column for storing homomorphic encrypted data;

If the data columns for storing the fully homomorphic encryption data are included, determining an auxiliary table to be queried corresponding to the data table to be queried, and acquiring ciphertext compression data blocks corresponding to the query conditions from the auxiliary table to be queried.

In an illustrated embodiment, the data query unit 807 is specifically configured to:

Determining an auxiliary table to be queried corresponding to the data table to be queried;

adding association information between the data table to be queried and the auxiliary table to be queried in the query statement;

Executing the query statement added with the association information to determine a compressed block identifier corresponding to at least one row of data meeting the query condition in the data table to be queried, and acquiring a ciphertext compressed data block corresponding to the compressed block identifier from the affiliated table to be queried.

In an illustrated embodiment, the apparatus 80 further comprises a data decryption unit 808 for:

acquiring at least one slot position identifier corresponding to the at least one row of data from the slot position identifier column of the data table to be queried;

the ciphertext compressed data block and the at least one slot position identifier are sent to the client so that the client decrypts the ciphertext compressed data block to obtain a plurality of plaintext compressed data; and

Determining at least one plaintext compressed data corresponding to the at least one slot position identifier from the plurality of plaintext compressed data, and decompressing the at least one plaintext compressed data to obtain decompressed at least one plaintext data.

In an illustrated embodiment, the apparatus 80 further comprises a data calculation unit 809 for:

Receiving a ciphertext compression parameter block corresponding to the ciphertext compression data block, which is sent by a client; the ciphertext compression parameter block comprises a plurality of ciphertext compression parameters obtained by compressing and fully homomorphic encrypting a plurality of plaintext parameters used for participating in calculation;

and executing ciphertext calculation based on the ciphertext compression data block and the ciphertext compression parameter block to obtain a ciphertext calculation result.

The implementation process of the functions and roles of each unit in the above-mentioned device 80 is specifically described in the above-mentioned corresponding embodiments of fig. 1 to 7, and will not be described in detail herein. It should be understood that the apparatus 80 may be implemented in software, or may be implemented in hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions into a memory by a processor (CPU) of the device. In addition to the CPU and the memory, the device in which the above apparatus is located generally includes other hardware such as a chip for performing wireless signal transmission and reception, and/or other hardware such as a board for implementing a network communication function.

The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical modules, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the units or modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

The apparatus, units, modules illustrated in the above embodiments may be implemented in particular by a computer chip or entity or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, vehicle-mounted computer, or a combination of any of these devices.

Corresponding to the method embodiments described above, embodiments of the present disclosure also provide a computer device. Referring to fig. 9, fig. 9 is a schematic structural diagram of a computer device according to an exemplary embodiment. As shown in fig. 9, the computer device includes a processor 1001 and a memory 1002, and may further include an input device 1004 (e.g., keyboard, etc.) and an output device 1005 (e.g., display, etc.). The processor 1001, memory 1002, input devices 1004, and output devices 1005 may be connected by a bus or other means. As shown in fig. 9, the memory 1002 includes a computer-readable storage medium 1003, which computer-readable storage medium 1003 stores a computer program executable by the processor 1001. The processor 1001 may be a CPU, microprocessor, or integrated circuit for controlling the execution of the above method embodiments. The processor 1001 may execute the steps of the data management method of the secret database in the embodiment of the present specification when executing the stored computer program, including: acquiring a table establishment statement for establishing a target data table in a secret state database; determining whether the target data table contains a data column for storing homomorphic encrypted data; if the data column for storing the full homomorphic encryption data is included, creating the target data table in the secret state database, and creating an affiliated table corresponding to the target data table; wherein the data column included in the target data table is used for storing indication information indicating that the data column does not store the fully homomorphic encryption data any more; the auxiliary table is used for storing ciphertext compression data blocks, and the ciphertext compression data blocks comprise a plurality of ciphertext compression data obtained by compressing a plurality of fully homomorphic encryption data to be written in, and the like.

For a detailed description of each step of the data management method of the above-mentioned secret database, please refer to the previous contents, and the detailed description is omitted here.

Corresponding to the above method embodiments, embodiments of the present description also provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the data management method of the cryptographic database in the embodiments of the present description. Please refer to the description of the corresponding embodiments of fig. 1-7, and the detailed description is omitted here.

The foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.

In a typical configuration, the terminal device includes one or more CPUs, input/output interfaces, network interfaces, and memory.

The memory may include volatile memory in a computer-readable medium, random Access Memory (RAM) and/or nonvolatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data.

Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, embodiments of the present description may take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

Claims

1. A method for data management of a cryptographic database, the method comprising:

2. The method of claim 1, wherein the attachment table includes a compressed block identification column and a compressed data column; the compressed block identification column is used for storing compressed block identifications corresponding to different ciphertext compressed data blocks respectively, and the compressed data column is used for storing different ciphertext compressed data blocks;

The method further comprises the steps of:

3. The method according to claim 2, wherein the method further comprises:

4. The method of claim 3, wherein the ciphertext compressed data block includes a plurality of slots that are in one-to-one correspondence with a plurality of slot identifiers, and wherein the plurality of ciphertext compressed data included in the ciphertext compressed data block are respectively located on the plurality of slots that are in one-to-one correspondence with the plurality of slot identifiers; the target data table further comprises a slot identification column for storing the slot identification.

5. The method according to claim 4, wherein the method further comprises:

6. The method of claim 5, wherein the method further comprises:

7. The method of claim 6, wherein the determining the affiliated table to be queried corresponding to the data table to be queried and obtaining the ciphertext compressed data block corresponding to the query condition from the affiliated table to be queried comprises:

8. The method of claim 7, wherein the method further comprises:

the ciphertext compressed data block and the at least one slot position identifier are sent to the client so that the client decrypts and decompresses the ciphertext compressed data block to obtain a plurality of plaintext data; and

And determining at least one plaintext data corresponding to the at least one slot position identifier from the plurality of plaintext data.

9. The method of claim 7, wherein the method further comprises:

10. A data management apparatus for a secure database, the apparatus comprising:

11. A computer device, comprising: a memory and a processor; the memory has stored thereon a computer program executable by the processor; the processor, when running the computer program, performs the method of any one of claims 1 to 9.

12. A computer readable storage medium, having stored thereon a computer program/instruction which, when executed by a processor, implements the method of any of claims 1 to 9.

13. A computer program product, characterized in that the computer program product comprises a computer program/instruction which, when executed by a processor, implements the method according to any one of claims 1 to 9.