Logical log generation in enclave database

Abstract

The embodiment of the invention relates to logical log generation in an enclave database. A database management system (DBMS) in an enclave for a data privacy protection database is provided. The system includes a DBMS engine configured to parse a database command for execution, set an access control state to a first state for a field of a data privacy preserving database when the parsed database command includes the field of the data privacy preserving database corresponding to a record in a system directory table, and record the database command into a logical log. When the access control state is set to the first state and the database command includes the content of the field, the DBMS engine is further configured to record a predetermined identifier, an identification of the field, and a length of the content immediately prior to the content in the logical log.

Description

Technical Field

[0001] Embodiments described herein generally relate to data privacy control of databases. More specifically, embodiments described herein relate to generating, encoding, and / or updating logical logs of a data privacy protected database by a database management system (DBMS) in an enclave. Background Art

[0002] Compared with software-oriented encrypted database (S-EDB) systems, traditional hardware-enabled encrypted databases (H-EDB) support more operations (e.g., database operations using Structured Query Language (SQL), etc.), but are still far lower than general-purpose database systems (e.g., SQL database systems, etc.). Traditional H-EDB systems typically have a partial hardware encryption (P-HE) architecture that uses a remote authentication (RA) mechanism to share client-side private keys and registers authenticated DBMS operator code within the enclave. Once ciphertext from one end (e.g., the user side, etc.) is passed (e.g., through the DBMS, etc.) to the enclave, the enclave first decrypts the ciphertext into plaintext, performs calculations or operations on the plaintext, and then encrypts the calculated plaintext (if necessary) before replying to the DBMS.

[0003] Generally, the design of P-HE databases is based on enclave constraints, such as those imposed by the trusted execution environment (TEE) memory limitations. Therefore, it may be impractical to authenticate the entire DBMS into the enclave to implement a fully hardware encrypted (F-HE) database system for runtime execution, and the input / output (I / O) costs in P-HE databases between the enclave and the DBMS may significantly affect system performance. Summary of the Invention

[0004] Recently emerging TEE memory increases can enable the creation of an F-HE architecture. Features in the embodiments disclosed herein can provide and otherwise implement an "in-enclave" (i.e., F-HE) database system (e.g., a relational database system, etc.) to support data privacy protection and verifiable functions by hosting the entire DBMS (or the entire database system) within the TEE (e.g., TEE memory, etc.), which can transform the current P-HE model.

[0005] It should be understood that in the F-HE database architecture, this mechanism can provide security and / or privacy protection by preventing data leakage from all memories, (multiple) processors (such as central processing units (CPUs) and I / Os). Therefore, an adversary can be prevented from viewing data structures and data repositories (such as system and physical logs) that are used internally by the DBMS and do not have an explicit retrieval interface. For example, the redo log of a database system (i.e., the physical log) stores all changes made to the database in a log file. Therefore, operations involving the redo log may include loading the redo log into memory and participating in processor (such as, CPU, etc.) calculations, being written and read as a log file by disk I / O, and being transmitted between replicas via network I / O. In the F-HE paradigm, operations related to the redo log do not leak data because the enclave memory and CPU are protected to ensure security and privacy; in addition, data can be encrypted by the enclave or TEE before being written to disk, and network transmissions can be protected via, for example, the Remote Authentication - Transport Layer Security (RA-TLS) protocol.

[0006] It should also be understood that in the F-HE database architecture, for data structures and data repositories with some explicit retrieval interfaces (such as, logical logs, etc.), additional security and / or privacy protection needs to be appropriately set. Features in the embodiments disclosed herein can provide logical log encoding or generation for, for example, enabling masked visibility control to implement an effective privacy-protected database logical log in F-HE, which can reform the client-side password in traditional P-HE databases (such as, using the RA mechanism, etc.). That is, features in the embodiments disclosed herein can achieve security and / or privacy protection without the need for a client password and the corresponding processes associated with the client password.

[0007] In one example embodiment, a database management system (DBMS) in an enclave for a data privacy-protected database is provided. The system includes a DBMS engine configured to parse database commands for execution, set an access control state to a first state for a field when the parsed database command includes a field of the data privacy-protected database corresponding to a record in the system catalog table, and record the database command in a logical log. When the access control state is set to the first state and the database command includes the content of the field, the DBMS engine is further configured to record a predetermined identifier, an identifier of the field, and a length of the content immediately preceding the content in the logical log.

[0008] In another exemplary embodiment, a method for logical records of a data privacy protection database is provided. The method includes parsing, by a DBMS engine of a database management system (DBMS), a database command for execution. The method further includes, when the parsed database command includes a field of the data privacy protection database corresponding to a record in a system catalog table, setting an access control state to a first state for the field and logging the database command in a logical log. When the access control state is set to the first state and the database command includes the content of the field, the method further includes logging a predetermined identifier, an identification of the field, and a length of the content immediately preceding the content in the logical log.

[0009] In yet another exemplary embodiment, a non-transitory computer-readable medium stores computer-executable instructions thereon. The instructions, when executed, cause one or more processors to perform operations including parsing, by a DBMS engine of a database management system (DBMS), a database command for execution. The operations further include, when the parsed database command includes a field of the data privacy protection database corresponding to a record in a system catalog table, setting an access control state to a first state for the field and logging the database command in a logical log. When the access control state is set to the first state and the database command includes the content of the field, the operations further include logging a predetermined identifier, an identification of the field, and a length of the content immediately preceding the content in the logical log. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings illustrate various embodiments of systems, methods, and other aspects of the present disclosure. Those of ordinary skill in the art will understand that the element boundaries shown in the figures (e.g., boxes, groups of boxes, or other shapes) represent one example of the boundaries. In some examples, one element may be designed as multiple elements, or multiple elements may be designed as one element. In some examples, an element that shows internal components of one element may be implemented as external components in another element, and vice versa. A non-limiting and non-exhaustive description is provided with reference to the following drawings. The components in the figures are not necessarily drawn to scale, but rather emphasis is placed on illustrating the principles. In the following detailed description, embodiments are described only as examples, as various changes and modifications will be apparent to those skilled in the art from the following detailed description.

[0011] Figure 1 is a schematic diagram of an exemplary data privacy protection database system arranged according to at least some embodiments described herein.

[0012] Figure 2 is a schematic diagram of an architecture of a database system according to at least some embodiments described herein.

[0013] Figure 3Schematic diagram of a logical log file of a data privacy protection database according to at least some embodiments described herein.

[0014] Figure 4 Flowchart showing an example processing flow of a logical log encoding or generation algorithm for a data privacy protection database system in an enclave according to at least some embodiments described herein.

[0015] Figure 5 Schematic structural diagram of an example computer system suitable for implementing an electronic device arranged according to at least some embodiments described herein. Detailed implementation

[0016] In the following detailed description, specific embodiments of the present disclosure are described with reference to the accompanying drawings, which form a part of the specification. In this specification and the accompanying drawings, unless the context otherwise indicates, the same reference numerals indicate elements that can perform the same, similar, or equivalent functions. Additionally, unless otherwise stated, the description of each successive drawing can refer to features from one or more previous drawings to provide a clearer context and a more substantial explanation for the current example embodiments. Nevertheless, the example embodiments described in the detailed description, the drawings, and the claims are not intended to be limiting. Other embodiments can be utilized, and other changes can be made without departing from the spirit or scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described and illustrated herein, can be arranged, substituted, combined, separated, and designed into a wide variety of different configurations, all of which are explicitly covered herein.

[0017] It should be understood that the disclosed embodiments are merely examples of the present disclosure, which can be embodied in various forms. Well-known functions or structures have not been described in detail to avoid obscuring the present disclosure in unnecessary details. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a basis for the claims and as a representative basis for teaching those skilled in the art to employ the present disclosure in any suitable detailed structure differently.

[0018] Furthermore, the present disclosure can be described herein in terms of functional block components and various processing steps. It should be understood that such functional blocks can be implemented by any number of hardware and / or software components configured to perform the specified functions.

[0019] The scope of the present disclosure should be determined by the appended claims and their legal equivalents, rather than by the examples given herein. For example, the steps recited in any method claim can be performed in any order and are not limited to the order presented in the claims. Additionally, no element is essential to the practice of the present disclosure unless specifically described herein as "critical" or "necessary".

[0020] As described herein, a "database" is a term that can refer to an organized collection of data or a type of data storage that can capture and analyze data based on a database management system (DBMS), software, applications, and / or the database itself that interact with end users. As described herein, a "database server" is a technical term that can refer to a server that uses a database application that provides database services to other computer programs or computers, as defined by the client-server model. It should be understood that some DBMSs can typically provide database server functionality, while some DBMSs can rely entirely on the client-server model for database access. It should also be understood that a DBMS can additionally include core facilities provided for managing the database; and the sum of the database, the DBMS, and related applications can be referred to as a database system. In an example embodiment, the database system can be a relational database system that can optionally use Structured Query Language (SQL) to query and update the database. It should also be understood that a database can include one or more database tables, each column of the database table indicating a specific variable or field, and each row in the database table corresponding to a given record or entry. The table can list the values for each of the variables or fields and / or each record or entry.

[0021] As described herein, a "DBMS engine" or "database engine" is a term that can refer to software or algorithms in a database system that identify and interpret database commands (e.g., SQL commands, etc.) to access the database and query the data in the database. In an example embodiment, the DBMS engine can include an SQL engine (or an SQL query engine).

[0022] As described herein, an "enclave" is a technical term that can refer to a trusted execution environment (TEE) that can protect sensitive data and code from attackers who control, attempt to control, or otherwise compromise the operating system and hypervisor on a host. It should be understood that an enclave or TEE can refer to a set of system resources (e.g., memory, input / output, a central processing unit, etc., a processor) that operate within a common security domain and share the protection of a single, common, continuous security perimeter. In an example embodiment, an enclave or TEE can refer to a private region of memory that is designed to be protected from processes running at a higher privilege level. It should also be understood that an enclave or TEE can refer to a secure area that helps protect the confidentiality and integrity of the code and data loaded therein. Data integrity prevents unauthorized entities outside the enclave or TEE from altering the data, while code integrity prevents the code in the enclave or TEE from being replaced or modified by unauthorized entities, which can include the computer owner or operator themselves. This can be achieved by implementing an architecture security that provides hardware-based memory encryption that isolates specific application code and data in the memory. An enclave or TEE can be an isolated execution environment that provides security functions such as isolated execution, the integrity of applications executed using the enclave or TEE, and the confidentiality of its assets. That is, an enclave or TEE can provide an execution space that provides a higher level of security for trusted applications running on a device than the operating system.

[0023] As described herein, "fine-grained" or "granular" data privacy preservation is a term in the art that can refer to a method, procedure, or system for preserving data privacy with respect to a portion or aspect of the data. In an example embodiment, a fine-grained data privacy protection database can provide a fine-grained data confidentiality protection mechanism, e.g., protecting the data privacy of one or more columns / fields (and / or one or more rows / records) of a database table. In contrast, "coarse-grained" data privacy protection is a term that can refer to a method, procedure, or system for protecting data privacy for broad data privacy control. In an example embodiment, a coarse-grained data privacy protection database can provide a coarse-grained data privacy protection mechanism, e.g., protecting the data privacy of an entire database table (e.g., based on a user's role or permissions, etc.), rather than a portion or aspect of the database table.

[0024] As described herein, the "logical log" in a database can be a term for a log file (e.g., a circular file, etc.) that can contain log records generated by a database server (e.g., a DBMS, etc.) to preserve the history of transactions and database server changes since the last storage space backup. The log records in the logical log indicate the logical operations of the database server, rather than the physical operations. As described herein, the "physical log" in a database can be a term for a log file that can contain the content of each row / record. Generally, the logical log records do not include the rows / records whose changes are recorded, but rather the database commands (e.g., SQL statements, etc.) that cause the rows / records to change (e.g., insert, update, and / or delete statements, etc.). The logical log can describe the changes in the form of record images or commands (e.g., SQL statements, etc.). The physical log records include the changed content of each row / record. The physical log can describe the changes in a way that is more oriented towards underlying data block operations. In an example embodiment, the logical log can include an audit log, while the physical log can include a redo log. It should be understood that although the logical log is used as an example when describing the features of the embodiments, any other suitable file having similar features to the logical log is applicable.

[0025] As described herein, the "system catalog" table in a database can be a term for the (multiple) tables and / or (multiple) views that describe the database structure. It should be understood that the system catalog table can refer to a data dictionary, which can contain everything the database knows about itself. It should also be understood that the system catalog table can refer to a metadata catalog, which serves as a repository for all the database objects that have been created. For example, when creating a database and other objects, the DBMS can automatically register information about them in the system catalog table. The DBMS can use the system catalog table to verify user requests for data, and users can query the system catalog table to obtain information about the database structure existing in the DBMS. The system catalog table can include information about database objects, schemas, programs, security, performance, communication, and / or other environmental details of the database it manages.

[0026] As described herein, "structured data" in a database is a term that can refer to pre-formatted data, the format of which is predefined in rows / records and columns / fields and is typically stored as a table. It should be understood that structured data can be classified as quantitative data and can be highly organized and easily understood by machine language. Structured data can be easily input, searched, and / or manipulated using a DBMS. In an example embodiment, a database table (e.g., a system catalog table, etc.) is structured data. As described herein, "unstructured data" in a database is a term that can refer to complex, qualitative, and / or unorganized data that may not conform to any one specific standard (e.g., unstructured data can be numbers, alphabets, boolean values, etc., or a mixture of some or all of them), and may not be stored in a database because the data string can have a mixed data type that cannot be placed in the rows / records or columns / fields of a table. In an example embodiment, a log file (e.g., a physical log, a logical log, etc.) is unstructured data.

[0027] Figure 1 is a schematic diagram of an example data privacy protection database system 100 arranged according to at least some embodiments described herein.

[0028] System 100 may include terminal devices 110, 120, 130, and 140, network 160, and / or server 150. It should be understood that server 150 can be a database server that provides database services to other computer programs or computers, as defined by the client-server model. Terminal devices 110, 120, 130, and 140 can be (multiple) devices for querying (or operating on, such as analyzing, processing, using, storing, sharing, accessing, etc.) a database on or from the server. It should also be understood that Figure 1 only an exemplary number of terminal devices, network, and server are shown. The embodiments described herein are not limited to the number of terminal devices, network, and / or server described. That is, the number of terminal devices, network, and / or server described herein is provided for descriptive purposes only and is not intended to be restrictive.

[0029] According to at least some example embodiments of the example embodiments, terminal devices 110, 120, 130, and 140 can be various electronic devices. The various electronic devices can include, but are not limited to, mobile devices such as smart phones, tablet computers, e-book readers, laptop computers, desktop computers, and / or any other suitable electronic devices.

[0030] According to at least some example embodiments of the example embodiments, network 160 may be a medium for providing a communication link between terminal devices 110, 120, 130, 140 and server 150. Network 160 may be the Internet, a local area network (LAN), a wide area network (WAN), a local interconnection network (LIN), the cloud, etc. Network 160 may be implemented through various types of connections, such as wired communication links, wireless communication links, fiber optic cables, etc.

[0031] According to at least some example embodiments of the example embodiments, server 150 may be a server that provides various services to users using one or more of terminal devices 110, 120, 130, and 140. Server 150 may be implemented by a distributed server cluster including multiple servers, or may be implemented by a single server. In an example embodiment, a DBMS may run on server 150.

[0032] Users may interact with server 150 via network 160 using one or more of terminal devices 110, 120, 130, and 140. Various applications or their localized interfaces, such as database applications, social media applications, online shopping applications, etc., may be installed on terminal devices 110, 120, 130, and 140.

[0033] It should be understood that software applications or services according to the embodiments described herein and / or according to the services provided by the service provider may be executed by server 150 and / or terminal devices 110, 120, 130, and 140 (which may be referred to herein as user devices). Accordingly, apparatuses for software applications and / or services may be arranged in server 150 and / or terminal devices 110, 120, 130, and 140.

[0034] It should also be understood that when the service is not remotely executed, system 100 may optionally include network 160 while including terminal devices 110, 120, 130, and 140 or server 150.

[0035] It should also be understood that the terminal devices 110, 120, 130, and 140, as well as the server 150, may each include one or more processors, memories, and storage devices storing one or more programs. Each of the terminal devices 110, 120, 130, and 140 and / or the server 150 may also each include an Ethernet connector, a Wi-Fi receiver, and the like. When one or more programs are executed by one or more processors, the one or more processors may be caused to execute the (s) method described in any of the embodiments described herein. In addition, it should be understood that a computer-readable non-volatile medium may be provided in accordance with the embodiments described herein. The computer-readable medium stores a computer program. When executed by a processor, the computer program is used to execute the (s) method described in any of the embodiments described herein.

[0036] Figure 2 is a schematic diagram of the architecture of a database system 200 according to at least some of the embodiments described herein. It should be understood that, unless otherwise specified, the processes disclosed herein may be executed by one or more processors (e.g., Figure 1 one or more processors of the terminal devices 110, 120, 130, and 140, Figure 1 the processor of the server 150, Figure 5 the central processing unit 505, and / or any other suitable processor).

[0037] As Figure 2 shown, the database system 200 includes a DBMS 210. In an example embodiment, the DBMS 220 may reside entirely within the enclave 220. The enclave 220 may be a trusted execution environment (TEE), which may be a set of encrypted system resources (e.g., memory, input / output, a processor such as a central processing unit, etc.). The DBMS 220 may include a DBMS engine 230. In an example embodiment, the DBMS engine 230 may be an SQL engine. The DBMS engine 230 may be designed, programmed, or otherwise configured to receive database commands (e.g., SQL statements, etc.) from the user 270 via the (s) application 260 to generate / create or operate / access / manipulate one or more database tables 290 and / or communicate with or control one or more internal or external tools or processes.

[0038] In an example embodiment, one or more database tables 290 may be loaded into the enclave 220 from the storage device 240 by the DBMS 210 and / or its engine 230 via an encrypted channel 245 (e.g., a trusted execution environment input / output transport layer security (TEE-IO TLS) channel, etc.). In an example embodiment, it may be saved, stored, or sent from the enclave 220 to the storage device 240 by the DBMS 210 via an encrypted channel 145.

[0039] In an example embodiment, the application 260 may execute on devices such as Figure 1 terminal devices 110, 120, 130, and 140 corresponding to or operated by the user 270 and / or Figure 1 the server 150. The user 270 may be the owner or operator of the database, a database administrator (DBA), an authorized user granted permission to access and / or modify the database of the database system 200, etc. The device corresponding to the user 270 may run the application 260 or instruct the application 260 to execute by, for example, providing the input 272 to the application 260 and / or receiving the output 272 from the application 260. The application 260 may communicate with the DBMS engine 230 via, for example, a secure network connection 265. The application 260 may be a fine-grained privacy protection application, a tamper-proof application, or any other suitable application(s).

[0040] In an example embodiment, a device corresponding to a user (not shown), such as Figure 1 terminal devices 110, 120, 130, and 140 and / or Figure 1 the server 150, may run or execute the application 250. The user may be the owner of the database, a database administrator (DBA), an authorized user granted permission to access and / or modify the database of the database system 200, etc. The application 250 may communicate with the DBMS 210 (and / or the DMBS engine 230) via, for example, (a) secure network connection(s) 255. The application 250 may be a coarse-grained privacy protection application or any other suitable application(s).

[0041] In an example embodiment, one or more database tables 290 may include system tables, such as (a) system catalog table(s), user-defined / generated tables, or any other suitable database tables, views, etc. One or more database tables 290 may be (a) database table(s) of a privacy protection database (e.g., a fine-grained privacy protection database, etc.).

[0042] For example, user 270 may be a human resources personnel. On the corresponding device, user 270 may create or generate a payroll (or database DB, not shown), which has columns / fields such as employee names, employee salaries, etc. The creation or generation of the payroll may be performed via interface 272 of application 260 (between application 260 and user 270), and application 260 sends corresponding database commands to DBMS engine 230 for execution (i.e., for creating or generating the payroll). That is, user 270 may be the owner of the payroll. When creating or generating the payroll, or afterwards, user 270 may send database command 275 (e.g., create the payroll and / or select or specify one or more fields (such as the salary field of the employee, etc.) as confidential or private columns / fields), so that DBMS engine 230 can create or update system catalog table 290. That is, the payroll is considered a fine-grained privacy protection table / database because parts of the table / database (such as the salary of the employee field, etc.) are protected, and no user (including the root user or DBA of DBMS 210, etc.) can view or access it except the owner 270 (and / or viewers to whom the owner 270 grants clear text viewing permissions for the (multiple) secret / private fields).

[0043] It should be understood that the database command 275 can be sent via the interface 272 of the application 260, and the application 260 can send the corresponding database command 275 to the DBMS engine 230 for execution. For example, it is used to create or update the system catalog table to add records / rows and / or insert or update (1) the unique identifier (e.g., UID1) of the secret column / field (such as the employee salary field) of the salary table to the column identifier (e.g., Col-ID) field, (2) the user identifier (e.g., User 1) of the salary table owner / creator to the table / database owner (e.g., Owner) field, and / or (3) the secret or privacy setting (e.g., High) of the UID1 of the salary table to the secret level (e.g., Sec-Level) field. In an exemplary embodiment, the user 270 (e.g., the creator or owner with the user name "User 1") can (e.g., via the interface 272) send a database command to the DBMS engine 230 to create, generate, or update a database table (e.g., with the table name "t1"), and define, specify, select, or designate a secret / private column / field (e.g., with the column name "c1"). For example, the database command can be "CREATE TABLE t1(c1 INT SECRET HIGH)", where "CREATE TABLE" indicates the operation or action of creating a database table, "t1" is the name of the database table to be created, "c1" is the field / column to be designated as a secret / private field / column, "INT" indicates the data type (such as an integer, etc.) in the c1 field / column, "SECRET" indicates that the column ("c1") is designated as a secret or private field / column, and "HIGH" indicates the secret level of the column ("c1").

[0044] It should also be understood that when the Sec-Level field is set or updated to "High" (or similar), the corresponding secret column / field (i.e., the salary in the employee field of the salary table, etc.) is not visible or accessible to any user other than the owner "User 1" of the corresponding table / database (e.g., the salary table) (and / or viewers whose clear-text viewing permissions for the (multiple) secret / private fields are granted by the owner), including the root user or DBA, etc., of the DBMS 210. When the Sec-Level field is set or updated to "Medium" (or similar), certain characteristics of the corresponding secret column / field (e.g., certain summaries of the employee salary, etc.) are visible or accessible to (multiple) users other than the owner and (multiple) viewers, subject to (multiple) other existing rules regarding user permissions. When the Sec-Level field is set or updated to "Low" (or similar), more characteristics of the corresponding secret column / field (compared to the "Medium" level) (e.g., some summaries of the employee salary, etc.) are visible or accessible to (multiple) users other than the owner and (multiple) viewers, according to (multiple) other existing rules regarding user permissions. In the exemplary embodiment, "High", "Medium", and "Low" can be numerical values arranged in increasing or decreasing order or sequence, depending on the configuration or definition of the levels. In another embodiment, the secret level (e.g., Sec-Level) field can be optional.

[0045] It should also be understood that the device corresponding to user 270 can also send database commands (not shown) via the interface 272 of the application 260, and the application 260 sends the corresponding database commands to the DBMS engine 230 for execution, i.e., for creating or updating the system catalog table to add / update records / rows and / or (1) insert or update the (multiple) viewers of the secret column / field (e.g., the salary field of the employee) of the salary table into the viewer list (e.g., viewer) field, (2) add, edit / update, or delete the secret / private field / column, and / or (3) add, edit / update, or delete the value of the secret level, etc. In the exemplary embodiment, regardless of the value of the "Sec-Level" field, the secret column / field (e.g., the salary in the employee field of the salary table, etc.) is visible to the owner (e.g., User 1) and (multiple) viewers listed in the "Viewer" field.

[0046] It should also be understood that secret / private field(s) visible to the user may indicate that the user can view the plaintext of the value / data of the secret / private field(s). Secret / private field(s) invisible (or not visible) to the user may indicate that the user may not view the plaintext of the value / data of the secret / private field(s), may not view the secret / private field(s) at all, and / or may view masked data of the secret / private field(s). In an example embodiment, the masked data may indicate that the data is encoded, encrypted into ciphertext, masked by adding (one or more) random values, and / or the plaintext of the data is prevented from being viewed.

[0047] In an example embodiment, the DBMS engine 230 may include a parser 282, a log manager 280, a runtime (or runtime manager, database manager, etc.) 284, and / or a data manager 286. It should be understood that one or more of the components (e.g., the parser, the log manager, the data manager, etc.) may be independent of the DBMS engine 230 (and not part of the DBMS engine 230). In such an embodiment, the DBMS engine 230 may communicate with the independent components (e.g., the parser, the log manager, the data manager, etc.), send commands to them, control, and / or operate the independent components.

[0048] It should be understood that the DBMS engine 230 may refer to a program (of the DBMS 210) that provides or serves as an interface between the data stored in the database (or the DBMS 210) and the applications and queries submitted to the DBMS 210 to ensure that the data is organized in a consistent and accessible manner. The DBMS engine 230 may allow end users to create, read, update, and / or delete information in the database.

[0049] In an example embodiment, the parser 282 may be configured to parse database commands such as SQL statements, queries, etc. In an example embodiment, the parser 282 may be part of an optimizer component, an optimization engine, and / or a query processor of the DBMS 210. It should be understood that the parser 282 may be configured to parse database access language requests and convert them into actionable commands, e.g., for accessing and modifying data in the database or the DBMS 210. The parser 282 may be configured to convert a user query into a series of low-level instructions for execution. For example, the parser 282 may be configured to read a user's query and convert it into a series of valid operations in a form that can be sent to the runtime 284 for execution. It should also be understood that the parser 282 may interact with the applications and queries submitted by the user, transform the operations in the user query, and may serve as an interface between the database, the user, and the application.

[0050] In an example embodiment, the runtime 284 can be configured to enable the DBMS 210 to centrally manage runtime data. For example, the runtime 284 can be configured to verify user authorization, process approved queries, determine which policy provides the best query results, ensure data integrity, and handle any other suitable tasks that need to process queries and runtime data. In an example embodiment, the runtime 284 can be referred to as a database control system, a database engine, or a database manager, which is the central software component of the DBMS 210 and processes database access at runtime. The runtime 284 can provide control to maintain the consistency, integrity, and security of the data in the DBMS 210.

[0051] In an example embodiment, the data manager 286 can be configured to store, process, and / or protect data, and provide controlled access and fast transaction processing to address the requirements of data-consuming applications. The data manager 286 can be used to manage access to the database and / or allow users to store information, modify data, and access data. The data manager 286 can be referred to as a cache manager and can be configured to process data in the database, provide recovery to the system, and allow it to recover data after a failure, etc.

[0052] In an example embodiment, the log manager 280 can be configured to record (e.g., log, write, store, etc.) data changes of different data operations (e.g., delete, insert, update, etc.) on user-definable database objects (tables, columns) in the database. It should be understood that the DBMS 210 can record all changes made to the data managed by the DBMS 210. The record of the changes can be referred to as a log. The log manager 280 can be configured to ensure that log records are made effectively and accurately and / or ensure data integrity. The log manager 280 can be configured to provide read and / or write access to the log and / or log tables to other resources / transaction managers of the DBMS 210. The log manager 280 can be configured to record, for example, database commands from users.

[0053] It should be understood that during the operation of the DBMS 210, the log manager 280 may record (e.g., save, store, record, etc.) database commands (e.g., SQL statements, etc.) that cause database changes such as row / record changes (e.g., insert, update, and / or delete statements, etc.) into a logical log (which may be generated, updated, parsed, and / or manipulated by the log manager 280). It should be understood that unless otherwise explicitly stated, all database commands (e.g., SQL statements, etc.) including the above commands, such as generating, accessing, updating, inserting, deleting, operating, manipulating, and / or processing confidential / private column(s) / field(s), may be recorded in the logical log. That is, the log manager 280 may record data changes of different manipulation operations (e.g., delete, insert, update, etc.) on user-definable database objects ((multiple) tables, (multiple) column(s) / (multiple) field(s), etc.) in the database. It should also be understood that the log manager 280 may generate, update, parse, manipulate, and / or process any other suitable logs (e.g., system and / or physical logs, etc.).

[0054] Figure 3 FIG. is a schematic diagram of a logical log file 300 for a data privacy protection database according to at least some embodiments described herein. It should be understood that the logical log file 300 is for illustrative purposes only and is not intended to be limiting. It should also be understood that the logical log file 300 shows the sequence or order of the data, and the exact location of the data in the logical log file is not required.

[0055] It should be understood that the logical log 300 (e.g., audit log, etc.) may be configured or generated to record all changes made to a database (e.g., a fine-grained data privacy protection database). The logical log 300 may be created by a DBMS (e.g., a database server, a DBMS engine, and / or the log manager of the DBMS) and may contain records of all database commands (e.g., SQL statements, etc.) that modify the database data. In an exemplary embodiment, the logical log 300 may be used as an audit trail of the changes and may be used for various purposes such as data recovery, replication, and / or database monitoring. The data or content stored in the logical log 300 may be viewed in a human-friendly format using, for example, a database command (e.g., a request to retrieve the logical log). It should also be understood that the logical log 300 may be an unstructured file, and there is an unmet need to generate or update the logical log to facilitate locating the values, data, content, etc. of secret / private columns / fields in the logical log (which may be met by the features in the embodiments disclosed herein).

[0056] As Figure 2 described in the description, a logical log may be generated or updated during the operation of the DBMS 210 (e.g., Figure 3300). In an example embodiment, a user may send a database command to the DBMS engine 230 to create, generate, or update a database table and to define, specify, select, or designate a secret / private column / field. The database command may be "CREATE TABLE t1(c1 INT SECRET HIGH)". The user's identity may also be sent to the DBMS engine 230 along with the database command. The DBMS engine 230 (e.g., the parser 282) may parse the database command into an operation (e.g., in a form that can be sent to the runtime 284) for execution. The DBMS engine 230 (e.g., the runtime 284) may generate / create the database table t1. The DBMS engine 230 (e.g., the runtime 284) may also generate / create or update the system catalog table 290 to insert or update records such that (1) the "Owner" field of the record is inserted, updated, or replaced with the user's identity (e.g., "User 1" who sent the "CREATE TABLE" database command), (2) the "Col-ID" field in the record is inserted, updated, or replaced with the identity of the secret / private field / column (such as the identity of c1), and (3) the "Sec-Level" field in the record is inserted, updated, or replaced with the input value (such as "HIGH") in the database command. It should be understood that when the database command is to grant another user (e.g., "User 2") as a plaintext viewer of the secret / private field / column, the DBMS engine 230 (e.g., the runtime 284) may also generate / create or update the system catalog table 290 to insert or update the record such that (4) the "Viewer" field of the record is inserted, updated, or replaced with the identity of another user (e.g., "User 2") that may be included in the database command. The DBMS engine 230 (e.g., the log manager 280) may generate or update the logical log (e.g., Figure 3 300), and record the (multiple) database commands in the logical log. For the (multiple) database commands for content (or values, data, etc.) that do not contain secret / private columns / fields, the DBMS engine 230 (e.g., the log manager 280) may record the (multiple) database commands as plaintext data ( Figure 3 310A, 310B, 310C, 310D, etc.).

[0057] In an example embodiment, a user (e.g., the owner and / or viewer of a database table having secret / private columns / fields) may send a database command to the DBMS engine 230 to read, write, update, or access the content (or data, value, etc.) of the secret / private column / field. For example, the user may insert data into the database table (e.g., t1). The database command may be, for example, INSERT INTO t1 VALUES(1).

[0058] The DBMS engine 230 (e.g., the parser 282) can parse database commands into operations for execution (e.g., in a form that can be sent to the runtime 284). The runtime 284 can communicate with, for example, the data manager 286 to insert data into a database table (e.g., t1). The DBMS engine 230 (e.g., the data manager 286) can update the content of fields / columns and / or records / rows of a database table, including the content of secret / private fields / columns. It should be understood that in a structure (e.g., a runtime structure), the DBMS engine 230 (e.g., the runtime 284) can set an access control state (e.g., flags, bits, parameters, etc.) to a first predetermined value (e.g., a first state such as "TRUE", 1, etc.) for a secret / private field / column to indicate that the field / column (e.g., c1) is a secret / private field / column. If the field / column is not a secret / private field / column, the access control state of the field / column can be optional or can be set by the DBMS engine 230 (e.g., the runtime 284) to a second predetermined value (e.g., a second state such as "FALSE", 0, etc.) to indicate that the field / column is not a secret / private field / column. The DBMS engine 230 (e.g., the log manager 280) can generate or update a logical log (e.g., Figure 3 of 300), and record the (multiple) database commands in the logical log. For those (multiple) database commands that do not contain the content (or values, data, etc.) of secret / private columns / fields, the DBMS engine 230 (e.g., the log manager 280) can record the database commands as plaintext data ( Figure 3 of 310A, 310B, 310C, 310D, etc.). For those (multiple) database commands that contain the content (or values, data, etc.) of secret / private columns / fields (indicated by the access control state set by the DBMS engine 230 (e.g., the runtime 284)), the DBMS engine 230 (e.g., the log manager 280) can insert the corresponding secret column / field identifier ( Figure 3 of 350A, 350B, 350C, 350D, etc.), the corresponding column / field identification ( Figure 3 of 320A, 320B, 320C, 320D, etc.) and / or the corresponding length ( Figure 3 of 330A, 330B, 330C, 330D, etc.) before the content of the (multiple) secret / private columns / fields or the secret / private data ( Figure 3 of 340A, 340B, 340C, 340D, etc.).

[0059] Back to Figure 3, in an example embodiment, in the logical log 300, any data other than the secret / private data (i.e., content, value, or data) of the (multiple) secret / private columns / fields (such as database commands, SQL statements, etc.) can be recorded and / or displayed in its original form, for example, as plain text data (310A, 310B, 310C, 310D, etc.). In the logical log 300, for all the secret / private data of the (multiple) secret / private columns / fields, a corresponding secret column / field identifier (320A, 320B, 320C, 320D, etc.) is inserted before or immediately before the secret / private data (350A, 350B, 350C, 350D, etc.) of the (multiple) secret / private columns / fields in the logical log 300, along with the corresponding column / field identifier (330A, 330B, 330C, 330D, etc.) and / or the corresponding length (340A, 40B, 40C, 340D, etc.).

[0060] It should be understood that the secret column / field identifiers (320A, 320B, 320C, 320D, etc.) can be predefined or predetermined constants (the same for all secret column / field identifiers), for example, 256-bit (or 32-byte) constants, which can be used as identifiers for the data of the secret / private columns / fields. It should also be understood that the values of the secret column / field identifiers (320A, 320B, 320C, 320D, etc.) can be unique in the logical log and can be different from the values of all other data / content in the logical log. It should also be understood that the size of the column / field identifier (330A, 330B, 330C, 330D, etc.) can be predefined or predetermined (e.g., 16 bytes, etc.), and the value of the column / field identifier (330A, 330B, 330C, 330D, etc.) can indicate the identity of the secret / private column / field. The size of the "length" (340A, 340B, 340C, 340D, etc.) can be predefined or predetermined (e.g., two bytes, etc.), and the value of the length (340A, 340B, 340C, 340D, etc.) can indicate the data length of the secret / private data (350A, 350B, 350C, 350D, etc.) of the secret / private column / field. It should be understood that the column / field identifier (330A, 330B, 330C, 330D, etc.), the length of the secret / private data (i.e., the content of the secret / private field / column) (340A, 340B, 340C, 340D, etc.), and / or the secret / private data (350A, 350B, 350C, 350D, etc.) can be part of the corresponding database command or be derived from the corresponding (multiple) database commands.

[0061] In an example embodiment, consider that the value of the secret column identifier is 0xfffc (a predetermined value), the column identifier is 0x8001 (e.g., from a database command, via a parser and / or runtime), the secret / private data (the content of the secret / private field / column, e.g., from a database command, via an analyzer and / or runtime) is 0x1234 (i.e., the size of the secret / proprietary data is two bytes, or the size of the secret / private material is 0x0002, or the length is 0x0002), and the length of the secret / private information can be derived from the secret / private information itself. For such secret / private data (e.g., 0x1234), before recording the secret / proprietary data (e.g., 0x1234) in the logical log 300, the DBMS engine 230 (e.g., the log manager 280) can record the secret column identifier (e.g., 0xfffc, a predetermined value), followed immediately by the column identifier of the secret / private field / column (e.g., 0x8001), and then immediately followed by the length of the secret / private data (e.g., 0x000002). It should be understood that in the logical log 300, the length of the secret / private data (e.g., 0x0002) can be followed immediately by the secret / private data (i.e., the content of the secret / private field / column), and in the logical log 300, the recorded / recorded data can be 0xfffc800100021234 (e.g., 0x1234) of the secret / private data. It should be understood that the DBMS engine 230 (e.g., the log manager 280) can repeat the same process to record each secret / private data in the logical log 300. The generated or updated logical log 300 can provide a mechanism to easily identify or locate the secret / private data of the secret / private field / column.

[0062] For example, when a user sends a request to retrieve the logical log 300 via a device, the device may send a database command so that the output logical log can be returned to the user based on or in response to the request from the user. It should also be understood that the user's information (e.g., the user's identifier, etc.) may be included in the request to the DBMS. After receiving and responding to the user's request to retrieve the logical log 300, the DBMS engine (and / or the log manager) may parse the logical log 300 to detect or search for predefined secret column / field identifiers (320A, 320B, 320C, 320D, etc.). When any secret column / field identifier (320A, 320B, 320C, 320D, etc.) is detected or located, the DBMS engine (and / or the log manager) may mark the start of the position of the secret column / field identifier in the logical log 300 (e.g., the start offset) as L1, and read or retrieve or obtain the corresponding column / field identifier (330A, 330B, 330C, 330D, etc.) in the logical log 300 to probe or search or check the "Column Identifier" column / field in the system catalog table (e.g., Figure 2 the "Col-ID" column / field of the system catalog table 290). When the DBMS engine (and / or the log manager) finds that the corresponding column / field identifier (330A, 330B, 330C, 330D, etc.) obtained from the logical log 300 matches the value in the "Column Identifier" column / field in the system catalog table (e.g., Figure 2 the "Column ID" column / field of the system catalog table 290), the DBMS engine (or the log manager) may search the "Owner" and / or "Viewer" fields of the system catalog table to determine whether the user of the request (e.g., the logical log retrieval request) is one of the users in the "Owner" and / or "Viewer" fields of the system catalog.

[0063] When the DBMS engine (and / or the log manager) determines that the secret / private column / field corresponds to the obtained column / field identifier (330A, 330B, 330C, 330D, etc.) visible to the requesting user, the DBMS engine (or the log manager) then reads or retrieves or obtains the corresponding length (340A, 340B, 340C, 340D, etc.) (e.g., two bytes, etc.) in the logical log 300 to determine the length of the secret / private data (350A, 350B, 350C, 350D, etc.), and locates the end position of the secret / private data (350A, 350B, 350C, 350D, etc.) in the logical log 300 as L2. The DBMS engine (and / or the log manager) then locates the secret / private data (350A, 350B, 350C, 350D, etc.) buffer in the logical log 300, e.g., from the start position / address (e.g., L1 + 32 + 16 + 2, assuming the size of the secret column identifier is 32 bytes, the size of the column identifier is 16 bytes, and the size of the length in the logical log 300 is two bytes) to the end position / address (e.g., L2), to read or retrieve the confidential / private data (350A, 350B, 350C, 350D, etc.). The DBMS engine (and / or the log manager) then returns the output logical log to the user device (e.g., through the interface of the application communicating with the DBMS engine). It should be understood that the logical log can be the logical log 300 with the secret column identifier, column identifier, and / or length information removed for all secret / private columns / fields.

[0064] When the DBMS engine (and / or the log manager) determines that a secret / private column / field corresponding to the obtained column / field identifier (330A, 330B, 330C, 330D, etc.) is not visible to the requesting user, the DBMS engine (or the log manager) then reads, retrieves, or obtains the corresponding length (340A, 340B, 340C, 340D, etc.) (e.g., two bytes, etc.) in the logical log 300 to determine the length of the secret / private data (350A, 350B, 350C, 350D, etc.), and locates the end position of the secret / private data (350A, 350B, 350C, 350D, etc.) in the logical log 300 as L2. The DBMS engine (and / or the log manager) then locates the secret / private data (350A, 350B, 350C, 350D, etc.) buffer in the logical log 300, e.g., from the start position / address to the end position / address (e.g., L2), to first read or retrieve and then mask the secret / private data (350A, 350B, 350C, 350D, etc.) to be masked. The start position / address can be, for example, L1 + 32 + 16 + 2, assuming that in the logical log 300, the size of the secret column identifier is 32 bytes, the size of the column identifier is 16 bytes, and the size of the length is two bytes. The DBMS engine (and / or the log manager) then returns the output logical log containing the masked data to the user (e.g., via the interface of an application communicating with the DBMS engine). In an example embodiment, the masked data can indicate that the data is encoded, encrypted as ciphertext, masked by adding (a) random value(s), and / or otherwise prevented from viewing the plaintext of the data. It should be understood that the logical log can be the logical log 300 with the secret column identifier, column identifier, and length information removed for all secret / private columns / fields.

[0065] That is, based on the logical log 300, the output logical log may have had all secret column identifiers (320A, 320B, 320C, 320D, etc.), column identifications (330A, 330B, 330C, 330D, etc.), and length (340A, 340B, 340C, 340D, etc.) information removed therefrom. In the output logical log, for secret / private columns / fields visible to the requesting user (corresponding to the column identifications in the logical log 300), the secret / private data (350A, 350B, 350C, 350D, etc.) may be maintained (from the logical log 300). In the output logical log, for secret / private columns / fields not visible to the requesting user (corresponding to the column identifications in the logical log 300), the original or plaintext secret / private data (350A, 350B, 350C, 350D, etc.) (from the logical log 300) may not be maintained, but rather the secret / private data (350A, 350B, 350C, 350D, etc.) may be replaced with masked data of the secret / private data (350A, 350B, 350C, 350D, etc.) and in the output logical log. For other data in the logical log 300 (not prefixed with secret column identifiers (and corresponding column identifications and lengths)), no action may be taken, and the plaintext of this data may be returned to the user's device. It should be understood that the data returned to the user (requested) may be in the form of an output logical log, a data stream, or any other suitable format.

[0066] In an example embodiment, when no secret column / field identifiers (320A, 320B, 320C, 320D, etc.) are detected or located in the logical log 300 (i.e., no data with secret / private columns / fields is identified), the DBMS engine (and / or the log manager) may return the logical log 300 as the output logical log to the requesting user (to retrieve the logical log).

[0067] Figure 4 is a flowchart showing an example processing flow 400 of a logical log encoding or generation algorithm for a data privacy protection database system in an enclave according to at least some embodiments described herein.

[0068] It should be understood that unless otherwise specified, the processing flow 400 disclosed herein may be executed by one or more processors (e.g., Figure 1 processors of one or more of the terminal devices 110, 120, 130, and 140, Figure 1 processors of the server 150, Figure 5 the central processing unit 505, and / or any other suitable processor).

[0069] It should also be understood that the processing flow 400 may include one or more operations, actions, or functions, as shown by one or more of the blocks 410, 420, 430, 440, 450, 460, 470, and 480. For example, these various operations, functions, or actions may correspond to software, program code, or program instructions executable by a processor, which cause the functions to be performed. Although shown as discrete blocks, obvious modifications can be made, such as reordering two or more blocks; adding more blocks; and depending on the desired implementation, the various blocks can be divided into additional blocks, combined into fewer blocks, or eliminated. It should be understood that operations including initialization, etc. may be performed before the processing flow 400. For example, system parameters and / or application parameters may be initialized. It should be understood that Figure 2 and Figure 3 the processes, operations, or actions described in may be implemented or executed by a processor. The processing flow 400 may start at block 410.

[0070] In block 410 (defining secret fields), the processor may optionally receive or obtain a request (e.g., received from a user via a user interface of an application in a user device communicating with the DBMS or the DBMS engine) to create, define, set, update, select, specify, or designate one or more secret / private fields / columns of a database table, such as a fine-grained privacy-protected database, where the DBMS of the database or database system is fully located within an enclave. For example, the above request or database command "CREATE TABLE" may define a secret field (e.g., c1) in a database table (e.g., t1). After receiving the database command, the processor may parse the database command into operations to be performed. For example, the processor may create or generate a database table with one or more secret / private fields / columns. The processor may also generate / create or update a system catalog table to insert or update records in the system catalog table such that (1) the "Owner" field of the record is inserted, updated, or replaced with the identity of the user (e.g., "User1" who sent the request or database command), (2) the "Col-ID" field in the record is inserted, updated, or replaced with the identity of the secret / private field / column (e.g., the identity of c1), and (3) the "Sec-Level" field of the record is inserted, updated, or replaced with the input value (such as "HIGH") in the database command. After receiving a request, for example, to grant another user (e.g., "User 2") as a plaintext viewer of a secret / private field / column, the processor may also generate / create or update the system catalog table to insert or update records such that (4) the "Viewer" field of the record is inserted, updated, or replaced with the identity of another user (e.g., "User 2") that may be included in the database command. For database commands that do not contain the content (or values, data, etc.) of secret columns / fields, the processor may record the (multiple) database commands as plaintext data in a logical log. Processing may proceed from block 410 to block 420.

[0071] In block 420 (accessing secret data), the processor may receive or obtain a request (e.g., a request to read, write, update, or access the content (i.e., secret data) of one or more secret / private fields / columns of a database table from a user (such as the owner and / or viewer of a database table with secret / private columns / fields) via a user interface of an application in a user device communicating with the DBMS or the DBMS engine), such as a fine-grained privacy-protected database, where the DBMS of the database or database system is fully located within an enclave. In an example embodiment, the request or database command may be the above "INSERT INTO" database command. Processing may proceed from block 420 to block 430.

[0072] At block 430 (Parse database command), the processor may parse a database command (e.g., an “INSERT INTO” database command) into operations for execution. Processing may proceed from block 430 to block 440.

[0073] At block 440 (Set flag), the processor may read, write, update, or access the content of a field / column and / or record / row of a database table, including the content of a secret / private field / column. For example, upon receiving the above parsed request or the parsed database command “INSERT INTO”, the processor may insert data or content into the (multiple) field / (multiple) column (including the secret / private (multiple) field / (multiple) column, such as, c1) and / or the (multiple) record / (multiple) row (e.g., t1) of a database table. It should be understood that in a structure (e.g., a runtime structure), the processor may set an access control state (e.g., a flag, a bit, a parameter, etc.) to a first predetermined value (e.g., “TRUE”, 1, etc.) for a secret / private field / column to indicate that the field / column (e.g., c1) is a secret / private field / column. If the field / column is not a secret / private field / column, the access control state of the field / column may be optional, or may be set by the processor to a second predetermined value (e.g., “FALSE”, 0, etc.) to indicate that the field / column is not a secret / private field / column. Processing may proceed from block 440 to block 450.

[0074] At block 450 (Record database command), the processor may generate or update a logical log (e.g., Figure 3 of 300), and record the (multiple) database command in the logical log. Processing may proceed from block 450 to block 460.

[0075] At block 460 (Secret data?), if the processor may determine whether the data or content to be recorded in the logical log (e.g., in the database command) is the data or content of a secret / private field / column. If the data or content to be recorded is the data or content of a secret / private field / column, processing may proceed from block 460 to block 470. If the data or content to be recorded is not the data or content of a secret / private field / column, processing may proceed from block 460 to block 480.

[0076] At block 470 (Insert Prefix), for those (multiple) database commands that contain the content (or value, data, etc.) of secret / private columns / fields (indicated by the access control status set by the processor), the processor may insert the corresponding secret column / field identifier, the corresponding column / field identifier (of the secret field), and / or the corresponding length (of the secret field / secret data) before recording the content of the secret / private (multiple) columns / (multiple) fields or the secret / private data into the logical log. Processing may proceed from block 470 to block 480.

[0077] At block 480 (Record Data), for those (multiple) database commands that do not contain the content (or value, data, etc.) of secret / private columns / fields, the processor may record the (multiple) database commands as plaintext data into the logical log. For those (multiple) database commands that contain the content (i.e., secret data) of secret / private columns / fields (indicated by the access control status set by the processor), after inserting the prefix of the secret data at block 470, the processor may record the content of the secret / private (multiple) columns / (multiple) fields (e.g., secret data) as plaintext data into the logical log. It should be understood that although the secret data is recorded as plaintext data in the logical log, since the entire DBMS (including the logical log) is within the enclave, or the logical log can be stored in the storage device via an encrypted channel (e.g., a trusted execution environment input / output transport layer security (TEE-IOTLS) channel) (see Figure 2 description), the privacy of the secret data can be protected. When the user sends a request to retrieve the logical log, (1) the added prefix may be removed, and (2) the plaintext secret data (if the request is from the owner or viewer of the secret field) or the masked secret data (if the request is from a user other than the owner or viewer of the secret field) may be retrieved together with other plaintext data in the output logical log. The processor may return or distribute the output logical log to the requesting user (e.g., via the user interface of an application communicating with the DBMS or the DBMS engine).

[0078] Figure 5 is a schematic structural diagram of an example computer system 500 that is suitable for implementing an electronic device (e.g., Figure 1 one of the terminal devices such as the server or the terminal device shown in Figure 5 arranged according to at least some embodiments described herein). It should be understood that

[0079] As shown in the figure, computer system 500 may include a central processing unit (CPU) 505. The CPU 505 may perform various operations and processes based on programs stored in read-only memory (ROM) 510 or programs loaded from storage device 540 into random access memory (RAM) 515. The RAM 515 may also store various data and programs required for the operation of system 500. The CPU 505, ROM 510, and RAM 515 may be connected to each other via bus 520. An input / output (I / O) interface 525 may also be connected to bus 520.

[0080] Components connected to the I / O interface 525 may further include an input device 530, which includes a keyboard, a mouse, a digital pen, a graphics tablet, etc.; an output device 535, which includes a display such as a liquid crystal display (LCD), a speaker, etc.; a storage device 540 including a hard disk, etc.; and a communication device 545 including a network interface card such as a LAN card, a modem, etc. The communication device 545 may perform communication processing via a network such as the Internet, WAN, LAN, LIN, cloud, etc. In an embodiment, a drive 550 may also be connected to the I / O interface 525. A removable medium 555, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., may be installed on the drive 550 as needed, so that a computer program read from the removable medium 550 may be installed in the storage device 540.

[0081] It should be understood that the processes described in the flowchart with reference Figure 4 and / or the processes described in other figures may be implemented as computer software programs or hardware. A computer program product may include a computer program stored in a computer-readable non-volatile and non-transitory medium. The computer program includes program code for performing the methods shown in the flowchart and / or GUI. In this embodiment, the computer program may be downloaded and installed from a network via the communication device 545, and / or may be installed from the removable medium 555. When executed by the central processing unit (CPU) 505, the computer program may implement the above-mentioned functions specified in the methods in the embodiments disclosed herein.

[0082] It should be understood that the disclosures and other solutions, examples, embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuits, or in computer software, firmware, or hardware, including the structures disclosed in this document and their structural equivalents, or in a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, that is, one or more computer program instruction modules encoded on a computer-readable medium for execution by, or for controlling the operation of, a data processing device. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a substance composition that affects a machine-readable propagated signal, or a combination of one or more of them. The term "data processing device" includes all devices, apparatuses, and machines for processing data, such as programmable processors, computers, or multiple processors or computers. In addition to hardware, the apparatus may also include code that creates an execution environment for the computer program being discussed, for example, code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0083] A computer program (also referred to as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for a computing environment. A computer program does not necessarily correspond to a file in a file system. The program can be stored in a portion of a file that contains other programs or data (for example, one or more scripts in a markup language document), or in a single file dedicated to the program being discussed, or in multiple coordinated files (for example, files that store one or more modules, subroutines, or code portions). A computer program can be deployed to execute on one computer or at one site, or on multiple computers located at multiple sites and interconnected by a communication network.

[0084] The processes and logical flows described in this document can be executed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logical flows can also be executed by dedicated logic circuits, and the device can also be implemented as dedicated logic circuits, such as field programmable gate arrays, application specific integrated circuits, etc.

[0085] For example, processors suitable for executing computer programs include both general and special purpose microprocessors, as well as any one or more processors of any type of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more storage devices for storing the instructions and data. Generally, a computer will also include or be operatively coupled to receive data from, or transfer data to, one or more mass storage devices for storing data (such as magnetic disks, magneto-optical disks, or optical disks), or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and storage devices, such as semiconductor storage devices, such as erasable programmable read-only memory, electrically erasable programmable read-only memory, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and compact disc read-only memory and digital video disc read-only memory disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0086] It should be understood that various features, variations, and numerous different embodiments have been shown and described in detail. What is sometimes described in this application in terms of a particular embodiment is for illustrative purposes only and is not intended to limit or imply that only one particular embodiment or specific embodiment is contemplated. It should be understood that the disclosure is not limited to any single particular embodiment or recited variation. Many modifications, variations, and other embodiments will occur to those skilled in the art, and these modifications, variations, or other embodiments are intended to and are in fact covered by the disclosure. Indeed, the scope of the disclosure should be determined by the appropriate legal interpretation of the disclosure and the interpretation of the disclosure (including equivalents), as understood by those skilled in the art relying on the complete disclosure as it existed at the time of filing.

[0087] Aspect:

[0088] It should be understood that any one aspect can be combined with each other.

[0089] Aspect 1. A database management system (DBMS) in an enclave for a data privacy protection database, the system comprising: a DBMS engine configured to: parse database commands for execution; set an access control state to a first state for a field when the parsed database command includes a field of the data privacy protection database corresponding to a record in a system catalog table; log the database command to a logical log; and log a predetermined identifier, an identifier of the field, and a length of the content immediately preceding the content in the logical log when the access control state is set to the first state and the database command includes the content of the field.

[0090] Aspect 2. The system according to Aspect 1, wherein the first state of the field corresponds to the field being a private field, the first state indicating that the private field is invisible to the user, the database command being configured to access the content of the field, and the logical log being configured to record the database command.

[0091] Aspect 3. The system according to Aspect 2, wherein the record in the system catalog table includes a secrecy level and an identifier of the field, the DBMS engine being configured to set the access control state to the first state for the field when the secrecy level corresponding to the field is a predetermined value.

[0092] Aspect 4. The system according to Aspect 3, wherein upon receiving a request to set a field as a private field, the DBMS engine is configured to generate or update the record in the system catalog table to set the secrecy level corresponding to the field to a predetermined value, and wherein the request is independent of the database command.

[0093] Aspect 5. The system according to any one of Aspects 1 to 4, wherein the length of the content corresponds to the size of the content in the logical log.

[0094] Aspect 6. The system according to any one of Aspects 1 to 5, wherein the predetermined identifier has a unique value different from the database command to be recorded in the logical log.

[0095] Aspect 7. The system according to any one of Aspects 1 to 6, wherein the whole of the system is used for runtime execution in an enclave.

[0096] Aspect 8. A method for logical recording for data privacy protection of a database, the method comprising: parsing, by a DBMS engine of a database management system DBMS, a database command for execution; setting an access control state to a first state for a field when the parsed database command includes a field of a data privacy protection database corresponding to a record in a system catalog table; recording the database command in a logical log; and recording, in the logical log, a predetermined identifier, an identifier of the field, and the length of the content immediately preceding the content when the access control state is set to the first state and the database command includes the content of the field.

[0097] Aspect 9. The method according to Aspect 8, wherein the first state of the field corresponds to the field being a private field, the first state indicating that the private field is invisible to the user, the database command being configured to access the content of the field, and the logical log being configured to record the database command.

[0098] Aspect 10. The method according to Aspect 9, wherein the record in the system catalog table includes a secrecy level and an identifier of the field, the method further comprising: setting the access control state to the first state for the field when the secrecy level corresponding to the field is a predetermined value.

[0099] Aspect 11. The method according to aspect 10, the method further comprising: when receiving a request to set a field as a private field, generating or updating a record in a system catalog table to set a secrecy level corresponding to the field to a predetermined value, wherein the request is independent of a database command.

[0100] Aspect 12. The method according to claim 8, wherein the length of the content corresponds to the size of the content in the logical log.

[0101] Aspect 13. The method according to any one of aspects 8 to 12, wherein the predetermined identifier has a unique value different from the database command to be recorded in the logical log.

[0102] Aspect 14. The method according to any one of aspects 8 to 13, wherein the whole of the DBMS is used for runtime execution in an enclave.

[0103] Aspect 15. A non-transitory computer-readable medium having computer-executable instructions stored thereon, the instructions when executed causing one or more processors to perform operations including: parsing, by a DBMS engine of a database management system DBMS, a database command for execution; when the parsed database command includes a field of a data privacy protection database corresponding to a record in a system catalog table, setting an access control state to a first state for the field; recording the database command in a logical log; and when the access control state is set to the first state and the database command includes the content of the field, recording a predetermined identifier, an identifier of the field, and a length of the content immediately preceding the content in the logical log.

[0104] Aspect 16. The computer-readable medium according to aspect 15, wherein the first state of the field corresponds to the field being a private field, the first state indicates that the private field is invisible to a user, the database command is configured to access the content of the field, and the logical log is configured to record the database command.

[0105] Aspect 17. The computer-readable medium according to aspect 16, wherein a record in the system catalog table includes a secrecy level and an identifier of the field, and the operations further include: when the secrecy level corresponding to the field is a predetermined value, setting the access control state to the first state for the field.

[0106] Aspect 18. The computer-readable medium according to aspect 17, the operations further comprising: when receiving a request to set a field as a private field, generating or updating a record in the system catalog table to set a secrecy level corresponding to the field to a predetermined value, wherein the request is independent of a database command.

[0107] Aspect 19. The computer-readable medium according to any one of Aspects 15 to 18, wherein the predetermined identifier has a unique value different from the database command to be recorded in the logical log.

[0108] Aspect 20. The computer-readable medium according to any one of Aspects 15 to 19, wherein the DBMS as a whole is used for runtime execution within an enclave.

[0109] The terms used in this specification are intended to describe particular embodiments and are not intended to be limiting. Unless expressly stated otherwise, the terms "a," "an," and "the" also include the plural forms. When the terms "comprising" and / or "including" are used in this specification, they specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, and / or components.

[0110] Regarding the foregoing description, it should be understood that detailed changes may be made without departing from the scope of the present disclosure, particularly with respect to the shape, size, and arrangement of the construction materials and components used. The embodiments of this specification and are merely exemplary, and the true scope and spirit of the present disclosure are indicated by the appended claims.

Claims

1. A database management system (DBMS) in an enclave for a data privacy - protected database, the system comprising: A DBMS engine configured to: Parse database commands for execution; When the parsed database command includes a field of the data privacy - protected database corresponding to a record in the system catalog table, set the access control state to a first state for the field; Record the database command in a logical log; And When the access control state is set to the first state and the database command includes the content of the field, record a predetermined identifier, the identifier of the field, and the length of the content in the logical log.

2. The system according to claim 1, wherein the first state for the field corresponds to the field being a private field, the first state indicating that the private field is invisible to the user, The database command is configured to access the content of the field, and The logical log is configured to record database commands.

3. The system according to claim 2, wherein the record in the system catalog table includes a secrecy level and the identifier of the field, The DBMS engine is configured to: when the secrecy level corresponding to the field is a predetermined value, set the access control state to the first state for the field.

4. The system according to claim 3, wherein when receiving a request to set the field as the private field, the DBMS engine is configured to generate or update the record in the system catalog table to set the secrecy level corresponding to the field to the predetermined value, and Wherein the request is independent of the database command.

5. The system according to claim 1, wherein the length of the content corresponds to the size of the content in the logical log.

6. The system according to claim 1, wherein the predetermined identifier has a unique value different from the database command to be recorded in the logical log.

7. A method for logical recording for a data privacy - protected database, the method comprising: Parsing, by a DBMS engine of a database management system (DBMS), database commands for execution; When the parsed database command includes a field of the data privacy - protected database corresponding to a record in the system catalog table, setting the access control state to a first state for the field; Recording the database command in a logical log; And When the access control state is set to the first state and the database command includes the content of the field, recording a predetermined identifier, the identifier of the field, and the length of the content in the logical log.

8. The method according to claim 7, wherein the first state for the field corresponds to the field being a private field, the first state indicating that the private field is invisible to the user, The database command is configured to access the content of the field, and The logical log is configured to record database commands.

9. The method according to claim 8, wherein the record in the system catalog table includes a secrecy level and an identifier of the field, and the method further comprises: When the secrecy level corresponding to the field is a predetermined value, setting the access control state to the first state for the field.

10. The method according to claim 9, the method further comprises: Upon receiving a request to set the field as a private field, generating or updating the record in the system catalog table to set the secrecy level corresponding to the field to the predetermined value, wherein the request is independent of the database command.

11. A non-transitory computer-readable medium having computer-executable instructions stored thereon, the computer-executable instructions, when executed, cause one or more processors to perform operations, the operations including: Parsing, by a DBMS engine of a database management system DBMS, a database command for execution; When the parsed database command includes a field of a data privacy protection database corresponding to a record in the system catalog table, setting an access control state to a first state for the field; Recording the database command in a logical log; And When the access control state is set to the first state and the database command includes the content of the field, recording a predetermined identifier, an identifier of the field, and a length of the content in the logical log.

Images