Method and system for managing data in a database management system

Abstract

Methods and systems are provided for managing data in a database management system. The method includes storing data in a tense table in a database management system provided in a secure processing enclave, wherein the tense table includes a current table and a history table for storing the data; unique numbers are distributed to the stored data in the current table and the historical table respectively; and performing an operation provided in a database query language (DQL) statement for at least one of the stored data in the tense table. Performing the operation includes locating at least one of the stored data in at least one of the current table or the historical table based on the unique number; and performing the operation on at least one of the stored data.

Description

Technical Field

[0001] The embodiments described herein generally relate to methods and systems for managing data in a database. More specifically, the embodiments described herein relate to managing data in a tamper-proof database management system (DBMS) provided in a secure processing enclave, e.g., provided in a trusted execution environment (TEE). Background Art

[0002] Data management systems with tamper-proof and non-repudiation capabilities are emerging, where the data management system may include a ledger database system that may have blockchain-like characteristics (e.g., tamper-proof to prevent database record forgery and include auditability). For example, a software-supported verifiable database (S-VDB) system (i.e., a ledger database) provides tamper-proof and non-repudiation capabilities in a centralized architecture. However, most ledger databases focus on data-oriented verifiable mechanisms such as authenticated data structures (ADS), where a piece of data is computed as a hash digest, which can then be verified through ADS computation. Ledger databases may support query-oriented verifiability or structured query language operations, but neither is well supported in ledger database systems.

[0003] Data management systems may also use traditional hardware-supported verifiable databases (H-VDB) that focus on data-oriented verifiability. However, the performance of H-VDB is lower than that of S-VDB for TEE signatures, at least in part due to the significant input / output (I / O) cost between the enclave and the DBMS. Due to the constraints of memory limitations in the TEE, traditional H-VDB systems may use a partial hardware encryption (P-HE) architecture that shares client-side private keys, e.g., using a remote attestation (RA) mechanism and registering authenticated DBMS operation codes within the enclave, which may use a large number of calls between the enclave and the DBMS. Once a ciphertext from a terminal (e.g., a user side, etc.) is delivered to the enclave through the DBMS, etc., the enclave first decrypts the ciphertext into plaintext, performs computations or operations on the plaintext, and then encrypts the computed plaintext (if necessary) before replying to the DBMS.

[0004] Generally, P-HE databases are designed based on enclave constraints (e.g., trusted execution environment (TEE) memory limitations or constraints). 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. The input / output (I / O) cost in the P-HE database between the enclave and the DBMS may significantly affect system performance. Summary of the Invention

[0005] The recent emergence of the added TEE memory can enable the F-HE architecture. Features in the embodiments disclosed herein can provide an "in-enclave" (i.e., F-HE) database management system (e.g., a relational database management system, etc.) to support data privacy protection and verifiable functions by hosting the entire DBMS (or the entire database system) in a TEE (e.g., a secure processing enclave, e.g., TEE memory, etc.).

[0006] Features in the embodiments disclosed herein can also relate to a database management system that is provided to serve all trusted applications that require auditability, high-efficiency data performance, and / or query verifiability by leveraging TEE-supported advanced temporal tables, which significantly enhances the serviceability of a ledger database. In some embodiments, temporal tables can be used in a verifiable database, where the temporal tables meet privacy or regulatory requirements, e.g., the General Data Protection Regulation (GDPR 2016), and address the storage overhead limitations of immutable tables. For example, in an in-enclave architecture, a TEE-supported temporal table can be tamper-proof based on the fact that the DBMS is fully stored or provided in the enclave, e.g., not modifiable by an adversary (e.g., an unauthorized user who is not a designated user with restricted rights and / or privileges to the data), which was not possible previously due to the memory limitations of prior TEE systems. Additionally, advanced temporal tables can utilize unique numbers (such as serial numbers) to locate data in the temporal table to perform certain operations. The execution of certain operations can also be recorded in an audit table for auditability, e.g., recording metadata corresponding to the operation. Further, since the advanced temporal tables are TEE-supported, e.g., provided in a secure processing enclave, the temporal tables can be inherently tamper-proof.

[0007] In some embodiments, the DBMS can be a relational database, where database management programming languages (such as a database query language (DQL), such as Structured Query Language (SQL)) can be used to define transactions. Database operations can be executed using commands submitted in the form of DQL statements to a messaging interface or a front end that is designed, programmed, or otherwise configured to process DQL statements to allow certain operations to occur to actuate data in the (multiple) databases in the DBMS, e.g., database transactions.

[0008] In an example embodiment, a method for providing a tamper-proof database management system is provided. The method includes: storing data in a temporal table in a database management system provided in a secure processing enclave, where the temporal table includes a current table and a history table for storing data; respectively assigning unique numbers to the stored data in the current table and the history table; and performing an operation provided in a database query language (DQL) statement on at least one of the stored data in the temporal table. The step of performing the operation includes: locating at least one of the stored data in at least one of the current table or the history table based on the unique number; and performing the operation on at least one of the stored data.

[0009] In another example embodiment, a non-transitory computer-readable medium storing computer-executable instructions is provided. The computer-executable instructions, when executed, cause one or more processors to perform operations including: storing data in a temporal table in a database management system provided in a secure processing enclave, where the temporal table includes a current table and a history table for storing data; respectively assigning unique numbers to the stored data in the current table and the history table; and performing an operation provided in a database query language (DQL) statement on at least one of the stored data in the temporal table. Performing the operation includes: locating at least one of the stored data in at least one of the current table or the history table based on the unique number; and performing the operation on at least one of the stored data.

[0010] In yet another example embodiment, a tamper-proof database management system is provided. The database management system includes a processor configured to execute instructions and a temporal table for storing data. The temporal table includes a current table and a history table for storing data, where both the current table and the history table include unique numbers respectively assigned to the stored data. The processor is configured to execute instructions that, when executed, cause the processor to perform: performing an operation provided in a database query language (DQL) statement on at least one of the stored data in the temporal table. Performing the operation includes: locating at least one of the stored data in at least one of the current table or the history table based on the unique number; and performing the operation on at least one of the stored data. The tamper-proof database management system is provided in a secure processing enclave. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings illustrate various embodiments of the systems, methods, and various other aspects of the present disclosure. Any person skilled in the art will understand that the illustrated element boundaries in the accompanying drawings (e.g., boxes, groups of boxes, or other shapes) represent examples of 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 is shown as an internal component of one element may be implemented as an external component in another element, and vice versa. A non-limiting and non-exhaustive description is provided with reference to the following accompanying drawings. The components in the accompanying drawings are not necessarily drawn to scale, with the emphasis being on illustrating the principles. In the following detailed description, the embodiments are described by way of illustration only, as various changes and modifications will become apparent to those skilled in the art from the following detailed description.

[0012] Figure 1 is a schematic diagram of an example network for a tamper-proof database system arranged according to at least some embodiments described herein.

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

[0014] Figure 3 is a schematic diagram illustrating an example operation of a database management engine according to at least some embodiments described herein.

[0015] Figure 4 is a flowchart illustrating an example processing flow for providing a tamper-proof database system according to at least some embodiments described herein.

[0016] Figure 5 is a schematic structural block diagram of an example computer system suitable for implementing an electronic device arranged according to at least some embodiments described herein. Detailed Description

[0017] 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 description. In this specification and the accompanying drawings, unless the context otherwise requires, the same reference numerals denote elements that can perform the same, similar, or equivalent functions. Additionally, unless otherwise stated, the description of each successive drawing may refer to features from one or more previous drawings to provide a clearer context and a more substantial explanation of the current example embodiments. However, the example embodiments described in the detailed description, the drawings, and the claims are not intended to be limiting. Other embodiments may be used and other changes may 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 generally described and illustrated in the drawings can be arranged, substituted, combined, separated, and designed in a variety of different configurations, all of which are explicitly contemplated herein.

[0018] 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 configurations are not described in detail to avoid unnecessarily obscuring the present disclosure. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but only as a basis for the claims and as a representative basis for teaching those skilled in the art to use the present disclosure in various ways in almost any appropriate detailed structure.

[0019] In addition, the present disclosure may 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.

[0020] 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 claim. Additionally, no element is essential to the practice of the present disclosure unless specifically described herein as "critical" or "necessary".

[0021] As referred to herein, "database" is a technical term and can refer to an organized collection of data or a type of stored data based on the use of a database management system (DBMS), software that interacts with end-users, applications, and the database itself to capture and analyze data. As referred to herein, "database server" is a technical term and can refer to a server of 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 typically provide database server functionality, and 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 the associated applications can be referred to as a database system. In an example embodiment, the database system can be a relational database system equipped with the option to query and update the database using a database query language (DQL) such as Structured Query Language (SQL). It should also be understood that a database can include one or more database tables, each column of the database table representing a specific variable or field, and each row of the database table corresponding to a given record or entry. The table can list the values of each variable or field and / or the values of each record or entry in the variables or fields.

[0022] As referenced herein, a "database management system" (DBMS) is a technical term that can refer to a computer program or collection of computer programs for creating and managing databases. The DBMS can execute on one or more processor-enabled devices (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerator, etc.) in a database system. The DBMS can allow interaction with the databases it manages to perform operations such as data creation, erasure, hiding, querying, and control.

[0023] As referenced herein, a "DBMS engine" or "database engine" is a technical 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 databases and interrogate or elicit data in the databases. In an example embodiment, the DBMS engine can include an SQL engine (or SQL query engine).

[0024] As referenced 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 group of system resources (e.g., memory, input / output, processors such as a central processing unit, etc.) that operate within a common security domain and share a single common continuous security boundary. 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 to help protect the code and data loaded therein with respect to confidentiality and integrity. Data integrity prevents unauthorized entities outside the enclave or TEE from altering data, while code integrity prevents the code in the enclave or TEE from being replaced or modified by unauthorized entities (which can also be the computer owner itself). This can be achieved by implementing confidential architecture security that provides hardware-based memory encryption that isolates specific application code and data in memory. An enclave or TEE can be an isolated execution environment that provides security features such as isolated execution, integrity of applications executed using the enclave or TEE, and 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 compared to the operating system.

[0025] As referred to herein, "fine-grained" or "granular" data privacy protection is a technical term and can refer to a method, procedure, or system for protecting data privacy with respect to a specific part or aspect of data. In an example embodiment, a fine-grained data privacy protection database can refer to a database that provides a fine-grained data privacy protection mechanism (e.g., to protect 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 technical term and can refer to a method, procedure, or system for protecting data privacy for generalized data privacy control. In an example embodiment, a coarse-grained data privacy protection database can refer to a database that provides a coarse-grained data privacy protection mechanism (e.g., to protect the data privacy of an entire database table (e.g., based on a user's role or permissions, etc.) rather than a specific part or aspect of the database table).

[0026] As referred to herein, "data" or "data set" is a technical term and can refer to an organized collection of data that can be stored and accessed electronically. In an example embodiment, data can refer to a database, a data table, a part of a database or a data table, etc. It should be understood that data can correspond to one or more database tables, where each column of the database table represents a specific variable or field, and each row of the database table corresponds to a given record of the data set. Data can list the values of each variable and / or the values of each record of the data. It should also be understood that a data set can also or alternatively refer to a set of related data and the way the related data is organized. In an example embodiment, each record of the data set can include (a plurality of) fields or (a plurality of) elements, such as one or more predefined or predetermined identifiers (e.g., a user identifier, such as a user's name, email address, phone number, the user's unique ID, etc.), and / or one or more attributes or characteristics or values associated with one or more identifiers.

[0027] As referred to herein, "metadata" can refer to descriptive information about data, or "data about data". Metadata can carry individual characteristics related to operations and / or information about data, such as the type of operation, the executor of the operation, the number of data affected, the timestamp, etc.

[0028] As referred to herein, "temporal table" is a technical term and can refer to a database feature that provides built-in support for providing information about the data (e.g., metadata) stored in a table at any point in time. Temporal tables can be used to track the history of data changes. In some embodiments, a temporal table can include a current table that stores current data (e.g., the latest data, such as currently relevant data or data that can be used by the owner or a designated user of the data), and a history table that contains outdated data (e.g., deleted or changed data).

[0029] As referred to herein, a "tamper-proof" or "tamper-resistant" system may refer to a system in which data is accessible (e.g., viewable, selectable, and / or retrievable) and / or modifiable only by a designated user (such as the owner of the data or someone designated or permitted by the owner of the data to access and / or modify the data (e.g., a system administrator or a trusted third party)). That is, an adversary (e.g., a user other than the designated user) is restricted and thus cannot or is prevented from viewing, modifying, and / or accessing the data in the tamper-proof database management system. For example, since the DBMS is in a secure processing enclave, the adversary cannot change or modify the data. "Tamper-proof" or "tamper-resistant" may also refer to a verification process in which a signature can be used to verify the integrity of the result set data (e.g., verify that the data has not been tampered with), or can be used to verify the designated user.

[0030] While previous database management systems had poor performance and could not reduce storage overhead, which led to a large amount of storage consumption, the methods, procedures, and systems discussed herein are provided to serve trusted applications that require auditability, high-efficiency data performance, and / or query verifiability by leveraging TEE-supported advanced temporal tables, which significantly enhances the serviceability of the ledger database. In some embodiments, temporal tables can be used in a verifiable database, where the temporal tables meet privacy or regulatory requirements, such as the General Data Protection Regulation (GDPR 2016), and address the storage overhead limitations of immutable tables. For example, in an enclave architecture, the TEE-supported temporal table can be tamper-proof based on the DBMS being fully stored or provided in the enclave, e.g., not modifiable by an adversary (e.g., an unauthorized user who is not the designated user with restricted rights and / or privileges to the data), which was not possible previously due to the memory limitations of previous TEE systems. Additionally, the advanced temporal table can utilize a unique number (e.g., a serial number) to locate data in the temporal table to perform certain operations. The execution of certain operations can also be recorded in an audit table for auditability, e.g., recording the metadata corresponding to the operation. Further, since the advanced temporal table is TEE-supported, e.g., provided in a secure processing enclave, the temporal table can be inherently tamper-proof.

[0031] In some embodiments, the DBMS can be a relational database, where a database management programming language such as Structured Query Language (SQL) can be used to define transactions. Database operations can be performed using commands submitted in the form of SQL statements to a messaging interface or a front end that is designed, programmed, or otherwise configured to process the SQL statements to allow certain operations to occur to stimulate the data in the (multiple) databases in the DBMS, e.g., database transactions.

[0032] Figure 1A schematic diagram of an example network for a tamper-proof database management system that can provide auditability, high-efficiency data performance, and / or query verifiability.

[0033] System 100 may include terminal devices 110, 120, 130, and 140, network 160, and / or server 150. It should be understood that server 150 may 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 may be devices for querying (or operating, e.g., analyzing, processing, using, storing, sharing, accessing, etc.) a database on or from the server. It should also be understood that Figure 1 Only an illustrative number of terminal devices, networks, and servers are shown. The embodiments described herein are not limited to the number of terminal devices, networks, and / or servers described. That is, the number of terminal devices, networks, and / or servers described herein is for descriptive purposes only and is not intended to be limiting.

[0034] According to at least some example embodiments, terminal devices 110, 120, 130, and 140 may be various electronic devices. The various electronic devices may 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. Terminal devices 110, 120, 130, and 140 may be client devices that include applications (or application programming interface (API) connections) (such as SQL clients and / or verification APIs, web access programs (e.g., browsers), or other Internet-enabled programs for accessing the data management system on server 150 to initiate database transactions with server 150). Terminal devices 110, 120, 130, and 140 may also include security programs, access keys, certificates, signatures, encryption programs, etc. in order to be able to access server 150.

[0035] According to at least some 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 interconnect 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.

[0036] According to at least some example embodiments, server 150 can be a server that includes a database management system (DBMS) provided within an enclave or a secure processing enclave (e.g., a TEE that can protect data and code from adversaries or attackers). The DBMS can include a front end for communicating with terminal devices 110, 120, 130, 140 and can receive inputs from the terminal devices for processing. The inputs can be transactions or requests for the (multiple) databases managed by the DBMS. The requests can contain commands in the form of a database query language (DQL), e.g., SQL statements, which define database transactions to be executed on the (multiple) databases, where the DQL statements can be processed by the front end. The DBMS can include a set of designated users who can be authorized to perform operations on the (multiple) databases. The users can be assigned one or more roles, which in turn can be associated with one or more permissions, or the users can be directly associated with one or more permissions. The permissions associated with the users (directly or indirectly) specify what operations the users are authorized and not authorized to initiate related to the (multiple) databases. Unauthorized users (or users who are not designated users) can be considered adversaries who may attempt to access the data without authorization, e.g., they may attempt to tamper with the data. Server 150 can be implemented by a distributed server cluster that includes multiple servers or can be implemented by a single server.

[0037] Users can interact with server 150 using one or more of terminal devices 110, 120, 130, and 140 via network 160. Various applications or native interfaces (e.g., SQL clients) can be installed on terminal devices 110, 120, 130, and 140. The users can be client devices for sending inputs (e.g., SQL statements) to initiate the databases.

[0038] It should also be understood that each of terminal devices 110, 120, 130, and 140 and / or server 150 can include one or more processors, memories, and storage devices that store one or more programs. Each of terminal devices 110, 120, 130, and 140 and / or server 150 can also include an Ethernet connector, a Wi-Fi receiver, etc. When executed by one or more processors, the one or more programs can cause the one or more processors to perform the (multiple) methods described in any of the embodiments described herein. It should also be understood that a computer-readable non-volatile medium can be provided in accordance with the embodiments described herein. The computer-readable medium stores a computer program. The computer program is for performing the (multiple) methods described in any of the embodiments described herein when executed by a processor.

[0039] Figure 2It is a schematic diagram of the architecture for the DBMS 270 according to an example embodiment. The DBMS 270 can be a virtual machine executed on a processor-enabled server and / or multiple servers provided through a cloud computing network or infrastructure, for example, for video and content distribution and / or data processing. In an example embodiment, the DBMS 270 can reside entirely within the secure processing enclave 275. The enclave 275 can be a trusted execution environment (TEE), which can be a set of encrypted system resources (e.g., memory, input / output, processors such as central processing units, graphics processing units, security hardware, security software, etc.). The DBMS 270 can include a DBMS engine 280. In some embodiments, the secure processor within the enclave can also communicate with (one or more) unsecured databases (e.g., provided outside the enclave 275 (e.g., TEE)).

[0040] In an example embodiment, the DBMS engine 280 can be a DQL engine, e.g., an SQL engine. The DBMS engine 280 can be designed, programmed, or otherwise configured to receive database commands (e.g., SQL statements, etc.) from the user 210 via (one or more) applications 215 to generate / create or operate / access / manipulate one or more database tables 282, 284, and / or communicate with or control one or more tools or processes (e.g., a log manager). That is, the DBMS engine 280 can be designed, programmed, or otherwise configured to execute any received DQL statement within the enclave 275 and can access the storage database 290. The DBMS engine 280 can parse the DQL statement, which can include requests to read selected data stored in the secure storage database 290, write data to the secure storage database 290, or modify data stored in the secure storage database 290. In some embodiments, the DQL statement can also include instructions or operations to erase or hide data stored in the temporal table 286, which can be audited by data (e.g., metadata) stored in the audit table 288 paired with the temporal table 286.

[0041] In an example embodiment, one or more database tables 282, 284 may be loaded into the enclave 275 from a storage device 290 by, for example, a DBMS 270 via an encrypted channel 295 (such as a Trusted Execution Environment - Input / Output Transport Layer Security (TEE-IO TLS) channel, etc.). In an example embodiment, one or more database tables 282, 284 may be saved in, stored in, or sent to the storage device 290 by, for example, a DBMS 270 via an encrypted channel 295 in the enclave 275. In some embodiments, one or more database tables 282, 284 may include system tables, such as (multiple) system catalog tables, (multiple) ledger tables, (multiple) user-defined / generated tables, (multiple) log tables, (multiple) visibility catalogs, (multiple) summary tables, or any other suitable database tables, views, etc., which include data that can be arranged in rows and columns to represent the relationships of the data stored in the (multiple) databases 290 and the user's access rights to the data. In some embodiments, one or more (multiple) database tables 282, 284 may be defined by a DBMS 270 and / or a user (such as a designated user) using trusted features (e.g., via a Data Definition Language (DDL)). Once one or more (multiple) database tables 282, 284 are defined, one or more (multiple) database tables 282, 284 may further include (multiple) temporal tables 286, where the (multiple) temporal tables 286 may include a current table and a historical table paired with an audit table 288. The temporal tables 286 and / or the audit table 288 may contain metadata to support the valid data and query verifiability of the data stored in the (multiple) databases, e.g., for accessing, auditing, and / or verifying any target stored data. In some embodiments, the stored data in the temporal tables may only be accessed and / or modified by a designated user, i.e., restricted to such a designated user for access and / or modification.

[0042] In an example embodiment, a user 210 may run an application 215 on a client device such as Figure 1 terminal devices 110, 120, 130, and 140 and / or Figure 1 a server 150. The client device may include applications (or Application Programming Interface (API) connections), such as an SQL client and / or a verification API, a web access program (e.g., a browser), or other Internet-enabled programs for accessing a data management system 270 (e.g., for initiating database transactions with a DBMS and / or a server). The client device may also include security programs, access keys, encryption programs, etc., in order to be able to access the server and / or the DBMS 270.

[0043] User 210 may be a designated user, e.g., the owner of the database, a database administrator (DBA), an authorized user granted the right to access and / or modify data in the database of database system 270, etc. User 210 may run application 215 by, for example, providing input 212 to application 215 and / or receiving output 212 from application 215. Application 215 may communicate with DBMS engine 280 via, for example, secure network connection 272. Application 215 may be a fine-grained privacy protection application, a tamper-proof application, or any other suitable application(s).

[0044] In an example embodiment, a user (not shown) (which may or may not be User 210) may run an application 216 on a device such as Figure 1 terminal devices 110, 120, 130, and 140 and / or Figure 1 server 150. This user may also be a designated user, such as the owner of the database, a database administrator (DBA), an authorized user granted the right to access and / or modify the database of database system 270, etc. Application 216 may communicate with DBMS 270 (and / or DBMS engine 280) via, for example, (a) secure network connection(s) 273. Application 216 may be a coarse-grained privacy protection application or any other suitable application(s).

[0045] Figure 3 is an example embodiment of the operation of a DBMS (e.g., Figure 2 270) that uses a temporal table 386 and an audit table 388 to support a blockchain-like tamper-proof function and, according to one embodiment, may also be used to address storage overhead limitations and support efficient data and query verifiability that meets data privacy requirements. Temporal table 386 and audit table 388 may include any features of the (a) temporal table(s) and / or (a) audit table(s) discussed herein (e.g., temporal table 286 and audit table 288).

[0046] In some embodiments, a DBMS may include a DBMS engine, e.g., 280. The DBMS engine may be a DQL engine, such as an SQL engine, and may be designed, programmed, or otherwise configured to receive database commands (e.g., SQL statements, etc.) from a user (e.g., 210) via an (a) application(s) (e.g., 215) to generate / create or operate / access / manipulate one or more database tables (e.g., 282, 284), and / or communicate with or control one or more tools or processes. That is, the DBMS engine may be designed, programmed, or otherwise configured to execute any received DQL statement within the enclave and may access a storage database (e.g., 290). The DBMS engine may parse the DQL statement, which may include requests to read selected data stored in the secure storage database, write data to the secure storage database, or modify data stored in the secure storage database. In some embodiments, the DQL statement may further include instructions or operations to erase or hide data stored in the temporal table 386, which may be audited by data in an audit table 388 paired with the temporal table 386. In some embodiments, the DQL statement may include confirming that the user is the designated user by using a signature confirmation (e.g., an SQL statement including "WITH SIGNATURE") to confirm that the user has a high-privilege role for accessing, modifying, or selecting certain data using the operation and / or for verifying that the user authentication table data and query result sets have not been modified, e.g., a TEE-supported result set.

[0047] In some embodiments, one or more (a) database table(s) may be defined by a DBMS having trusted characteristics (e.g., via a data definition language (DDL)). Once one or more (a) database table(s) are defined, the one or more (a) database table(s) may further include (a) temporal table(s) 386. The (a) temporal table(s) 386 may include a current table 386A and a history table 386B paired with an audit table 388 for storing data corresponding to data stored in the storage database. The current table 386A may store current data (e.g., the latest data), while the history table 386B may store old data (e.g., outdated or changed data from the current table 386A). The temporal table 386 and / or the audit table 388 may contain metadata to support valid data and query verifiability of the data stored in the (a) database(s), e.g., for accessing, auditing, and / or verifying any target data (e.g., stored data), while maintaining the auditability of the entire temporal table, e.g., to have a blockchain-like tamper-proof function and / or immutability.

[0048] In some embodiments, the temporal table 386 may include an implicit column for a unique number, which may be used as an identifier for storing data and may be used as a unique search key. Thus, the unique number may not necessarily be monotonic, which can reduce overhead transaction processing by providing efficient data and query processing capabilities. That is, while traditional temporal tables may be designed as immutable tables containing timestamp information, where the stored data can be retrieved through timestamp filters, the unique number in the temporal table 386 can allow advanced functionality by providing a unique search key for targeted search of stored data, such that the stored data can be effectively located and queried while maintaining the audibility of the stored data. In this way, the temporal table 386 has advanced functionality, for example, by using the unique number that can be used to locate the stored data to allow data erasure of one or more stored data (e.g., data stored before a certain timestamp) and to hide the data to meet regulatory compliance for data privacy protection. In some embodiments, the unique number may be a monotonically increasing sequence number associated with the stored data, but the unique number does not necessarily have to be consecutive. For example, there may be holes or gaps in the increasing number. For example, the unique number may include 1, 3, 4, 5, 6, where 2 is missing.

[0049] Return to Figure 3 , in an example embodiment of the operation of the DBMS engine (e.g., 280), the DBMS engine may be designed, programmed, or otherwise configured to execute any received DQL statement within the enclave. The DBMS engine may parse the DQL statement, which may include instructions, statements, or operations to be executed, such as erasing data stored in the temporal table 386 (e.g., to reduce storage overhead), obtaining data stored in the temporal table 386, selecting data stored in the temporal table 386, or hiding data stored in the temporal table 386 (e.g., for data privacy and protection). In some embodiments, the audit table 388 may be used to audit the instructions, statements, or operations to keep a record of the track.

[0050] For example, in some embodiments, to address the storage overhead issue (e.g., memory limitations of the TEE), a user (e.g., 210) may request to delete target data from the TEE, e.g., delete target data from one or more of the current table 386A or the historical table 386B. In some embodiments, the user may send a DQL statement to the DBMS engine, and an erase operation for erasing or deleting data (e.g., data stored before a certain timestamp) may be parsed from the DQL statement. The erase operation may be an operation that specifies an erase or delete operation for target stored data associated with a unique number. In some embodiments, the erase operation may be an SQL statement including a "DELETE" statement, or may be implicitly provided by the "not greater than or equal to" keyword or predicate or the "<=" keyword or predicate in the "DELETE" statement, where the DQL statement may specify a target unique number and / or any monotonically decreasing unique numbers for deletion. In some embodiments, the DQL statement may be specified as: "DELETE FROM T WHERE sn <=?". For example, if the "DELETE" statement includes the "not greater than or equal to" keyword or predicate for the unique number "00000003", data 1 and data 2 associated with the unique number "00000003" and the (multiple) unique numbers below this value (e.g., "00000001") will be erased from the current table 386A and the historical table 386B.

[0051] In some embodiments, to provide data privacy, for example, information or data that should not be made public and is related to an owner (e.g., salary, phone number, social security number, address, etc.), a user (e.g., 210) can request that the stored data be hidden, for example, in one or more of the current table 386A or the historical table 386B. In some embodiments, the user can send a DQL statement to the DBMS engine, where the hiding statement can be parsed from the DQL statement to hide any target data. In some embodiments, the hiding statement can be an SQL statement, or can be implicitly provided by an "equal to" predicate or "=" predicate on a "DELETE" statement, where the DQL statement can specify a target unique number. For example, the DQL statement can be specified as: "DELETE FROM T WHERE sn=?". For example, if the "DELETE" statement includes an "equal to" keyword or predicate for the unique number "00000006", the data 5 associated with the unique number "00000006" will be hidden in the current table 386A. That is, in some embodiments, the "DELETE" statement can be used for an erase or delete operation and / or a hiding operation, depending on the predicate on the "DELETE" statement.

[0052] In some embodiments, only those users with a high-privilege role (e.g., authorized users) can be authorized to perform any operations on the stored data, such as a "DELETE" statement with such predicates (e.g., accessing and / or modifying data). For example, in some embodiments, when the DQL statement includes a signature request (e.g., a "WITH SIGNATURE" statement), the high-privilege role of the specified user can be verified. In this way, the DBMS engine can be programmed, designed, or otherwise configured to verify that the user is the specified user with high privileges (e.g., via the certificate or storage of the specified user in a directory stored in the DBMS) to allow operations to be performed on the stored data. Although the "DELETE" statement has been discussed herein, this disclosure is not intended to be limiting. Instead, other statements can also be used to provide the desired operations, such as a hiding statement.

[0053] In some embodiments, to maintain a blockchain-like tamper-proof characteristic (e.g., an immutable-like characteristic) for data on a DBMS, the audit table 388 may be provided in pair with the temporal table 386 such that any change to the data in the temporal table 386 is recorded or stored in the audit table 388. The audit table 388 may include one or more data information (e.g., metadata) corresponding to the target stored data for recording or storing changes to the target stored data. The one or more data information may include the executor of the operation (e.g., the user who requests the operation), the operation type, a specified value of a unique number, the number of affected rows, a timestamp, etc. In some embodiments, the audit table 388 may be created and used only after an erase operation or a hide operation.

[0054] For example, as Figure 3 shown, after the DBMS engine performs a hide operation on the unique number "00000006", the data 5 and the associated stored data "789" may be hidden in the current table 386A such that an adversary cannot access, view, or modify the data 5, e.g., for the purpose of data privacy protection. As discussed above, the data 5 may be data related to the personal information of the owner, e.g., salary, phone number, address, social security number, etc., which may be used to identify the owner of the data. After the hide operation is performed, the hidden data may be recorded on the audit table 388 to maintain a record of the hidden data for auditability purposes. In some embodiments, the audit table 388 may include the data and metadata, such as, the unique number (e.g., "00000006"), the user (e.g., the system administrator (sysadm)), the transaction type (e.g., hide), the number of affected rows (e.g., 1), and the timestamp.

[0055] In another embodiment, after the DBMS engine performs an erase operation on the unique number "00000003", the unique number "00000003" in the current table 386A and the unique number "00000001" (along with the associated data 2 and data 1) in the historical table 386B can be erased or deleted to reduce the storage overhead in the TEE. After the erase operation is performed, the erased or deleted data can be recorded on the audit table 388 to maintain a record of the erased or deleted data for auditability purposes. In some embodiments, the audit table 388 can include data and metadata, such as, for example, a unique number (e.g., "00000003") (since the erase operation is identified for the unique number and the unique numbers below that value), a user (e.g., a system administrator (sysadm)), a transaction type (e.g., erase), the number of affected rows (e.g., 2 rows are affected, corresponding to the unique numbers "00000003" and "00000001"), and a timestamp. Although the audit table 388 has been discussed herein with respect to certain data and metadata associated with data, this disclosure is not intended to be limiting. Instead, other types of data information for tracking stored data can be used, identified, stored, or recorded on the audit table 388 for auditability.

[0056] Thus, the temporal table 386 and the audit table 388 are configured and / or provided to achieve practical regulatory compliance and overcome storage overhead limitations by providing a constraint predicate on the implicit unique number column to effectively locate any target data and maintain its auditability (e.g., all erased and hidden traces are recorded in the audit table). That is, by including at least an implicit column that includes a monotonically increasing unique number, the unique number can be used as an identifier to access, locate, and / or modify data, such that the data can be erased or deleted before a certain timestamp to reduce storage overhead, and / or to hide owner or user data for data protection and / or privacy protection, e.g., to meet regulatory compliance, such as GDPR. Although the present disclosure has been discussed herein with respect to monotonically increasing and / or decreasing, this disclosure is not intended to be limiting. Instead, other algorithms or methods can be used to specifically identify the data to be targeted, e.g., using a hash algorithm or other algorithms for coordinating and / or associating data with an identifiable value.

[0057] Figure 4 is a flowchart showing an example processing flow 400 for providing a tamper-proof database management system according to at least some embodiments described herein.

[0058] It should be understood that unless otherwise stated, the processing flow 400 disclosed herein can be performed by one or more processors (e.g., Figure 1a processor of one or more of the terminal devices 110, 120, 130, and 140, Figure 1 a processor of the server 150, a processor in a DBMS (e.g., Figure 2 the DBMS 270 and / or the DBMS engine 280), Figure 5 the central processing unit 505 and / or any other suitable processor) to execute.

[0059] 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 in blocks 410, 420, 430, 440, 450, and 460. These various operations, functions, or actions may correspond, for example, to software, program code, or program instructions executable by a processor, which causes the functions to be executed. Although illustrated as discrete blocks, obvious modifications can be made, for example, two or more blocks can be reordered; more blocks can be added; and various blocks can be divided into additional blocks, combined into fewer blocks, or eliminated according to the desired implementation. The processing flow 400 may start at block 410.

[0060] At block 410 (initialization), the processor of the corresponding device may execute an initialization function or operation for, for example, defining one or more database tables in a data management system provided in a secure processing enclave with trusted features via a data definition language (DDL). Once one or more database tables are defined, a TEE-assisted tamper-proof table, e.g., (multiple) temporal tables, can be defined using the IMMUTABLE keyword specified for the TEE (e.g., using the create statement of the table). In some embodiments, (multiple) temporal tables are created to include an implicit column SN, which can be used to store a unique number, such as a serial number associated with or corresponding to the stored data in the (multiple) temporal tables. (Multiple) temporal tables can be paired with audit tables. Temporal tables and / or audit tables may contain metadata to support the effective data and query verifiability of the data stored in the (multiple) databases, e.g., for accessing, auditing, and / or verifying any target stored data. Processing may proceed from block 410 to block 420.

[0061] At block 420 (store), the processor may store data in a temporal table in a database management system. The temporal table may include a current table and a history table for storing data, where the current table may store current data and the history table may store old or obsolete data. The data may include user identification such as the user's name, email address, salary, phone number, address, unique ID of the user, etc. The data storage may be authorized by a user, who may be a designated user such as the owner of the data or a person designated or permitted by the owner of the data to access and / or modify the data, e.g., a system administrator or a trusted third party. Processing may proceed from block 420 to block 430.

[0062] At block 430 (assign), the processor may assign unique numbers to the data in the current table and the history table, respectively. The unique numbers may be used as identifiers for storing the data and may be used as unique search keys, so the unique numbers may not necessarily be monotonic, which may reduce overhead transaction processing by providing efficient data and query processing capabilities. That is, while traditional temporal tables may be designed as immutable tables containing timestamp information, where the stored data may be retrieved through timestamp filters, the unique numbers in the temporal table may allow advanced features by providing unique search keys for targeting the stored data, such that the stored data may be effectively located and queried, e.g., to allow data erasure before a certain timestamp to reduce storage overhead and to hide data to meet regulatory compliance for data privacy protection. In some embodiments, the unique numbers may be monotonically increasing serial numbers associated with the stored data, but the unique numbers do not necessarily have to be consecutive, e.g., there may be holes or gaps in the increasing numbers, e.g., the unique numbers may include 1, 3, 4, 5, 6, where 2 is missing, etc. Processing may proceed from block 430 to block 440.

[0063] At block 440 (execute), the processor may execute an operation provided in a database query language (DQL) statement for at least one of the stored data in the temporal table. The execution of the operation may include locating at least one of the stored data in the current table and / or the history table based on the unique number and performing the operation on at least one of the stored data. The operations may include but are not limited to hide operations, erase operations, get operations, select operations, etc.

[0064] In some embodiments, to perform an operation, the processor may verify that the user is a designated user such that the stored data in the temporal table (and / or the data in the DBMS) is only accessible and / or modifiable after such verification. For example, access and / or modification of the data is restricted to the designated user. For example, in some embodiments, during the parsing of a DQL statement, a SELECT statement may be used to identify the TEE and a signature (e.g., the signature of the user matching the stored designated user) may be used to request verification, e.g., via a certificate, handshake, ID, etc. For example, the statement may include: "SELECT FROM T WITHSIGNATURE". In some embodiments, the verification may also allow the designated user to verify the data integrity of the result set from the query. For example, the designated user may check the TEE-supported signature in the result set to ensure that the data has not been modified or altered. In this way, a tamper-proof DQL statement may be provided and / or used to access and / or modify the data in the secure enclave and / or the DBMS by providing verification between the DBMS and / or the user, thereby further providing a tamper-proof function for the DBMS.

[0065] In some embodiments, to address storage overhead limitations (e.g., memory limitations of the TEE), previously immutable data from a blockchain ledger system may instead be deleted and / or modified by a designated user. For example, in some embodiments, the designated user may send a DQL statement to the DBMS that includes an erase operation that can be parsed and executed from the DQL statement to erase or delete data (e.g., the stored data corresponding to a certain timestamp and before that timestamp). The erase operation may be an operation that specifies an erase or delete operation for target stored data associated with a unique number. In some embodiments, the erase operation may be an SQL statement including a "DELETE" statement, or may be implicitly provided by a "not greater than or equal to" predicate or a "<=" predicate in the "DELETE" statement, where the DQL statement may specify the target unique number and / or any monotonically decreasing unique number for deletion. In some embodiments, the DQL statement may be specified as: "DELETE FROM T WHERE sn <=?". Although the erase operation has been discussed with respect to a monotonically decreasing unique number, this disclosure is not intended to be limiting. Instead, the erase operation may also target selected stored data, e.g., the stored data corresponding to a single unique number.

[0066] In some embodiments, to provide data privacy, for example, information or data related to an owner that should not be made public (e.g., salary, phone number, social security number, address, etc.), a designated user may request that target stored data be hidden (or erased), e.g., in one or more of a current table or a historical table. In some embodiments, the user may send a DQL statement to the DBMS engine, where the hide operation may be parsed from the DQL statement to hide any target data. In some embodiments, the hide operation may be an SQL statement or may be implicitly provided by an "equalto" predicate or "=" predicate on a "DELETE" statement, where the DQL statement may specify a target unique number. For example, the DQL statement may be specified as: "DELETE FROM T WHERE sn =?". That is, in some embodiments, the "DELETE" statement may be used for both an erase or delete operation and a hide operation, depending on the predicate on the "DELETE" statement. In some embodiments, only a high-privilege role (e.g., a designated user) may be authorized to execute a "DELETE" statement with such a predicate, e.g., an adversary is restricted from using such a statement. Although the "DELETE" statement has been discussed herein, this disclosure is not intended to be limiting. Instead, other statements may be used to provide the desired operation, e.g., a hide statement.

[0067] Processing may proceed from block 440 to block 450.

[0068] At block 450 (Create), after performing the operation provided in the DQL statement, the processor may optionally create an audit table paired with the temporal table such that any changes to the data in the temporal table are recorded or stored in the audit table, e.g., creating an audit trail for the data. The audit table may include one or more data information (such as metadata) corresponding to the target stored data for recording or storing changes to the target stored data. The one or more data information may include the executor of the operation (e.g., the user who requested the operation), the type of operation, the specified value of the unique number, the number of affected rows, and a timestamp. In this way, an audit table may be provided to support the blockchain-like tamper-proof function of the DBMS, e.g., by maintaining a record of any changes (e.g., due to an erase operation or a hide operation) to the data stored in the temporal table. Processing may proceed from block 450 to block 460.

[0069] At block 460 (verification), when a select statement specifying signature requirements is provided in the DQL statement, the processor can optionally send the table stored data and query result set to the specified user for verification. It should be understood that in the enclave architecture, the tamper-proof design is completely different from traditional P-HE systems. Different from P-HE tamper-proof database systems, the insertion operation is completely transparent, which means that any one of digest calculation, TEE trusted parameter combination, and TEE signature is no longer required, which is more efficient and practical. Instead, in some embodiments, as described above, the stored data and result set can be verified by adding the "WITH SIGNATURE" keyword to the select statement. In this way, the result set can be signed or supported by the TEE and can be verified on the client (e.g., user) side, which can guarantee the data integrity of the retrieved result set signed or supported by the TEE. For example, the data has not been tampered with by an adversary. The signature support can be used not only to verify tamper-proof data in temporal tables but also for common queries in any general (multiple) data tables. It should be understood that since the verification interface can be implemented or controlled by using the "WITH SIGNATURE" suffix keyword on the select statement, the general selection performance of the select statement may not be affected.

[0070] Figure 5 is a schematic structural diagram of an example computer system 500 arranged according to at least some of the embodiments described herein and suitable for implementing an electronic device (e.g., Figure 1 one of the terminal devices or servers in the terminal device shown). It should be understood that Figure 5 the computer system shown is for illustration only and does not limit the functions and applications of the embodiments described herein.

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

[0072] Components connected to the I / O interface 525 may also 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, which includes a hard disk, etc.; and a communication device 545, which includes a network interface card, such as a LAN card, a modem, etc. The communication device 545 can perform communication processing via a network such as the Internet, a FA WAN, a LAN, a LIN, the cloud, etc. In one embodiment, a driver 550 can 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., can be installed on the driver 550 as needed, so that a computer program read from the removable medium 555 can be installed in the storage device 540.

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

[0074] It should be understood that the disclosed 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 a combination of one or more of them. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more computer program instruction modules encoded on a computer-readable medium for execution by a data processing device 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 storage device, a substance composition implementing a machine-readable propagated signal, or a combination of one or more of them. The term "data processing device" encompasses all devices, apparatuses, and machines for processing data, including, for example, programmable processors, computers, or multiple processors or computers. In addition to the hardware, the device may also include code for creating an execution environment for the computer program being discussed, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0075] A computer program (also known 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 use in a computing environment. A computer program does not necessarily correspond to a file in a file system. The program can be stored in a part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), stored in a single file dedicated to the program being discussed, or stored in multiple coordinated files (e.g., files that store one or more modules, subroutines, or portions of code). A computer program can be deployed to be executed on one or more computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0076] The processes and logical flows described in this document can be performed 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 performed by dedicated logic circuitry, such as a field-programmable gate array, an application-specific integrated circuit, etc., and the apparatus can also be implemented as dedicated logic circuitry, such as a field-programmable gate array, an application-specific integrated circuit, etc.

[0077] Processors suitable for executing a computer program include, by way of example, both general and special purpose microprocessors, and 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 essential elements of a computer are a processor for executing instructions and one or more storage devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices, such as magnetic, magneto-optical, or optical disks, or operatively coupled to receive data from or transfer data to one or more mass storage devices, or both, although a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile or non-transitory memory, media, and storage devices, including, by way of example, 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 can be supplemented by, or incorporated in, dedicated logic circuitry.

[0078] It should be understood that various features, variations, and multiple different embodiments have been shown and described in detail. What is sometimes described in this application according to a particular embodiment is for illustrative purposes only and is not intended to limit or imply that the conceived subject matter is only a particular embodiment or a particular set of embodiments. It should be understood that the present disclosure is not limited to any single particular embodiment or enumerated variation. Many modifications, variations, and other embodiments will be apparent to those skilled in the art and are in fact covered by the present disclosure. Indeed, the scope of the present disclosure should be determined by appropriate legal interpretation and construction of the present disclosure, including equivalents that would be understood by those skilled in the art at the time of filing based on the complete disclosure.

[0079] Aspect:

[0080] It should be understood that any of the aspects can be combined with each other.

[0081] Aspect 1. A method for providing a tamper-proof database management system, the method comprising: storing data in a temporal table in a database management system provided in a secure processing enclave, wherein the temporal table includes a current table and a history table for storing the data; assigning unique numbers to the stored data in the current table and the history table respectively; and performing an operation provided in a database query language (DQL) statement on at least one of the stored data in the temporal table; wherein performing the operation includes: locating at least one of the stored data in at least one of the current table or the history table based on the unique number; and performing the operation on at least one of the stored data.

[0082] Aspect 2. The method according to aspect 1, wherein the operation includes at least one of erasing, selecting, retrieving, or hiding.

[0083] Aspect 3. The method according to any one of aspects 1 to 2, wherein access and / or modification of the stored data in the temporal table is restricted to a specified user.

[0084] Aspect 4. The method according to any one of aspects 1 to 3, further comprising creating an audit table for recording any changes to at least one of the stored data in the temporal table, wherein recording the changes includes recording at least one value of the unique number and metadata associated with the change to the at least one stored data.

[0085] Aspect 5. The method according to aspect 4, wherein the metadata includes one or more of the following items: type of operation performed, performer of the operation, timestamp, or number of rows the operation is directed to.

[0086] Aspect 6. The method according to any one of Aspects 1 to 5, wherein the unique number is a serial number sequentially assigned to data stored in both the current table and the historical table.

[0087] Aspect 7. The method according to any one of Aspects 1 to 6, wherein the historical table stores obsolete data and the current table stores current data.

[0088] Aspect 8. The method according to Aspect 3, wherein the access and / or modification of the stored data in the temporal table is performed by verifying that the user is the specified user, wherein the verification includes verification of a signature.

[0089] Aspect 9. The method according to any one of Aspects 1 to 8, wherein the DQL statement includes a "not greater than" predicate, and the "not greater than" predicate is an erase operation.

[0090] Aspect 10. The method according to any one of Aspects 1 to 9, wherein the DQL statement includes an "equal" predicate, and the "equal" predicate is a hide operation.

[0091] Aspect 11. A non-transitory computer-readable medium storing computer-executable instructions that, when executed, cause one or more processors to perform operations, the operations including: storing data in a temporal table in a database management system provided in a secure processing enclave, wherein the temporal table includes a current table and a historical table for storing the data; respectively assigning unique numbers to the stored data in the current table and the historical table; and performing an operation provided in a database query language (DQL) statement on at least one of the stored data in the temporal table; wherein performing the operation includes: locating at least one of the stored data in at least one of the current table or the historical table based on the unique number; and performing the operation on at least one of the stored data.

[0092] Aspect 12. The non-transitory computer-readable medium according to Aspect 11, wherein the operation includes at least one of erase, select, fetch, or hide.

[0093] Aspect 13. The non-transitory computer-readable medium according to any one of Aspects 11 to 12, wherein the processor is further configured to perform an operation of creating an audit table for recording any changes to at least one of the stored data in the temporal table, wherein recording the changes includes recording at least one value of the unique number and metadata associated with the changes to at least one of the stored data.

[0094] Aspect 14. The non-transitory computer-readable medium according to any one of Aspects 11 to 13, wherein access to and / or modification of the data stored in the temporal table is restricted to a specified user.

[0095] Aspect 15. The non-transitory computer-readable medium according to any one of Aspects 11 to 14, wherein the access to and / or the modification of the stored data in the temporal table is performed by verifying that the user is the specified user, wherein the verification includes verification of the signature of the user.

[0096] Aspect 16. The non-transitory computer-readable medium according to any one of Aspects 11 to 15, wherein the DQL statement includes a "not greater than" predicate, and the "not greater than" predicate is an erasure operation.

[0097] Aspect 17. The non-transitory computer-readable medium according to any one of Aspects 11 to 16, wherein the DQL statement includes an "equal" predicate, and the "equal" predicate is a hiding operation.

[0098] Aspect 18. A tamper-proof database management system, comprising: a processor configured to execute instructions; a temporal table for storing data, wherein the temporal table includes a current table and a history table for storing the data, and wherein both the current table and the history table include unique numbers respectively assigned to the stored data; wherein the processor is configured to execute the instructions, and the instructions, when executed, cause the processor to: for at least one of the stored data in the temporal table, perform an operation provided in a database query language (DQL) statement, wherein performing the operation includes: locating the at least one of the stored data in at least one of the current table or the history table based on the unique number; and performing the operation on the at least one of the stored data, and wherein the tamper-proof database management system is provided in a secure processing enclave.

[0099] Aspect 19. The database management system according to Aspect 18, wherein the secure processing enclave further includes an audit table for recording any changes to at least one of the stored data in the temporal table, and wherein the audit table includes at least one value of the unique number and metadata associated with the change to at least one of the stored data.

[0100] Aspect 20. The database management system according to any one of Aspects 18 to 19, wherein access to and / or modification of the stored data in the temporal table is restricted to the specified user by verifying the signature of the specified user.

[0101] The terms used in this specification are intended to describe particular embodiments and are not intended to be limiting. Unless otherwise expressly indicated, the terms "a," "an," and "the" also include plural forms. As used in this specification, the terms "comprising" and / or "including" 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.

[0102] In regard to the foregoing description, it should be understood that changes may be made in details, particularly in the materials of construction used and in the shape, size, and arrangement of the parts, without departing from the scope of the disclosure. The specification and the described embodiments are merely exemplary, and the true scope and spirit of the disclosure are indicated by the appended claims.

Claims

1. A method for providing a tamper-proof database management system, the method comprising: storing data in a temporal table in a database management system provided in a secure processing enclave, wherein the temporal table includes a current table and a history table for storing the data; Assigning unique numbers to the stored data in the current table and the historical table respectively; as well as For at least one of the stored data in the temporal table, execute an operation provided in a database query language DQL statement; The operations include: locating the at least one of the stored data in at least one of the current table or the historical table based on the unique number; as well as The operation is performed on the at least one of the stored data. 2 . The method of claim 1 , wherein the operation comprises at least one of erasing, selecting, acquiring, or hiding. 3 . The method of claim 1 , wherein access to and / or modification of the stored data in the temporal table is restricted to specified users.

4. The method according to claim 1, further comprising: An audit table is created for recording any changes to the at least one of the stored data in the temporal table, wherein the recording changes comprises recording at least one value of the unique number and metadata associated with the change to the at least one stored data. 5 . The method of claim 4 , wherein the metadata comprises one or more of a type of operation performed, a performer of the operation, a timestamp, or a number of rows targeted by the operation. 6 . The method according to claim 1 , wherein the unique number is a serial number sequentially assigned to the data stored in both the current table and the history table. The method according to claim 1 , wherein the history table stores outdated data, and the current table stores current data.

8. The method according to claim 3, wherein the access and / or the modification of the stored data in the temporal table is performed by verifying that the user is the designated user, wherein the verification includes verification of a signature.

9. The method of claim 1 , wherein the DQL statement includes a “not greater than” predicate, the “not greater than” predicate being an erase operation.

10. The method of claim 1, wherein the DQL statement includes an "equality" predicate, the "equality" predicate being a hidden operation.

11. A non-transitory computer-readable medium having computer-executable instructions stored thereon, which when executed cause one or more processors to perform the method according to any one of claims 1-10.

12. A tamper-proof database management system, comprising: A processor is configured to execute instructions, wherein when the instructions are executed, the processor performs the method according to any one of claims 1-10.

Images