Database access control service in a network

Abstract

A system supporting a network database service includes a controller configured to receive one or more data requests and authenticate the one or more data requests. A gateway (GW) in communication with the controller is configured to receive at least one of the one or more data requests from the controller, perform data classification on data received in the request, and generate a cryptographic key from the data classification, a hardware protection key of the GW, and a second (encryption) key. The cryptographic key is used to access a database. The controller and the GW are operated by different parties.

Description

[0001] Cross-referencing related applications

[0002] This application claims priority to U.S. Application No. 16 / 920,623, filed July 3, 2020, entitled “Database Access Control Service in Networks,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] This invention relates to database access control, and more particularly to methods and systems for protecting privacy when accessing databases in a network environment. Background Technology

[0004] Data outsourcing, or "database as a service (DBaaS)," is a new paradigm in data management where a third-party service provider offers database as a service. DBaaS provides data management for its clients. The benefits of DBaaS include that clients do not need to purchase or provide their own hardware, install database software, or manage the database themselves, nor do they need to perform necessary upgrades and backups to ensure the availability and security of the database system.

[0005] DBaaS also enables multi-party data sharing and data exchange. The participants in DBaaS include data providers, data requesters, database providers, and DBaaS service providers. A data provider is an entity that provides data to be stored in the database. The data uploaded to the database can be confidential or proprietary data of the data provider. A data requester is an entity that requests access to data or data-driven reports within the stored data. A database provider provides database storage and a database engine, and in many applications, is a cloud computing provider. The database provider must protect the privacy and confidentiality of the data provided by the data provider. The database provider also accesses the database provider's data according to the data provider's data access permissions. The DBaaS service provider must manage data access and protect the privacy, confidentiality, and access permissions of all parties (including themselves). In some embodiments, all parties can be separate entities. In other embodiments, a single entity can perform the roles of multiple parties.

[0006] Current technologies used to protect confidentiality can be called zero-knowledge privacy, which relies on key managers and asymmetric encryption.

[0007] When using zero-knowledge privacy, database providers offer zero-knowledge privacy, where the data provider encrypts their own data and uploads the encrypted data to the database. The database provider does not know the data and does not have access to the data encryption key. Examples of database providers offering zero-knowledge privacy include cloud service providers, Tresorit, pCloud AG, and Sync.com Inc. If the server is accessed without permission, no one other than the data provider can access the data because only the data provider possesses the encryption key. However, if the data provider wants to share its data with a data requester or a third party, the data provider must download the data from the database and then securely send it to the data requester or third party. This process consumes network resources and is impractical if the data provider uses mobile devices such as smartphones or tablets or Internet of Things (IoT) devices.

[0008] Some applications rely on using a third party or agent to encrypt data. This third party or agent stores the shared key and retrieves it from a storage device separate from the key generator used to encrypt the data. An external key server or key manager can be used, and it can also generate its own encryption keys. Examples include Vormetric Transparent Encryption and Trend Micro Inc.'s SecureCloud. This allows data requesters to download and decrypt data using the encryption key from the third party, agent, or key manager. However, a malicious data requester could access the database without the data provider's authorization and retrieve the provider's data using the same shared key.

[0009] Asymmetric encryption has also been proposed as a technical solution. Asymmetric encryption allows a semi-trusted agent to convert data encrypted using one user's public key into data decrypted using another user's private key. However, to meet long-term security requirements, long symmetric keys of 4096 bits or 8192 bits are needed, making it impractical to encrypt data on some user devices with limited storage and computing power.

[0010] Data management solutions are needed to protect the confidentiality of data providers' data, ensure that data requesters and database providers are authorized and authenticated before allowing access to data, and provide a trusted third party to independently manage the DBaaS system.

[0011] The purpose of the background art is to disclose information that the applicant believes may be relevant to the present invention. It is neither necessary nor appropriate to acknowledge that any of the foregoing information constitutes prior art in relation to the present invention. Summary of the Invention

[0012] This invention provides a system for implementing "Privacy Database Access Control (PDAC)" and providing PDAC as a Service (PDACaaS) to data providers, data requesters, database providers, and DBaaS service providers. The embodiments also provide an architecture for providing PDACaaS that protects and enhances the privacy of data providers and authenticates and controls access to data stored in a database. The embodiments provide database access control with customizable security levels to meet the various security requirements of participating parties.

[0013] According to an embodiment of the present invention, a system is provided. The system includes: a controller configured to receive one or more data requests and authenticate the one or more data requests. Such a system further includes a gateway (GW) communicating with the controller. The GW is configured to: receive from the controller a response corresponding to at least one of the one or more data requests; receive data from a data provider; perform data classification on the data based on the response to obtain a classification result; and generate a cryptographic key for accessing a database, wherein the cryptographic key is based on the classification result, a hardware protection key in the GW, and a key from the data provider. The cryptographic key is used to access the database. The controller and the database are operated by different parties.

[0014] This system embodiment separates data storage services from access control services. This allows data storage and data access / control services to be provided by different entities, thereby enhancing data security and privacy. This embodiment also provides customizable security levels based on data characteristics.

[0015] In other embodiments, the GW is an entry GW, and the one or more data requests include data upload requests. The entry GW is further configured to: send the data upload request to the controller, encrypt the data according to the cryptographic key, and send the encrypted data to the database for storage. This embodiment is used to ensure secure communication between the data provider and the system.

[0016] In other embodiments, the one or more data requests include a data access request from a data requester. The controller is further configured to: authenticate and authorize the data access request, and send a data indication to the egress GW. The system also includes: an egress GW configured to perform data classification on the received data indication to obtain a second classification result; receive data from the database; and generate a decryption key based on the second classification result, the hardware protection key of the egress GW, and the key of the data provider. The egress GW uses the decryption key for accessing the database to provide the data requested in the data access request. For example, the egress GW decrypts the data based on the decryption key and provides the decrypted data to the data requester. This embodiment is used to ensure secure communication between the system and the entity requesting access to data. In other embodiments, the ingress GW, the egress GW, and the controller are operated by the same party, which is different from the party operating the database.

[0017] In other embodiments, the data received by the ingress GW is encrypted data from the data provider. In other embodiments, the ingress GW is further configured to decrypt the encrypted data from the data provider using the data provider's key to obtain decrypted data, wherein the data encrypted by the ingress GW is the decrypted data. In other embodiments, the egress GW is configured to decrypt the data using the decryption key and the data provider's key. In other embodiments, the system further includes: a data distribution center, configured to: receive the encrypted data from the ingress GW, select the database to store the encrypted data, and store the address of the database in a log server; the ingress GW is configured to send the encrypted data to the database for storage through the data distribution center. In other embodiments, the controller is further configured to authenticate the data provider through an authentication center. In other embodiments, the controller is configured to authorize the data access request by confirming with the data provider that the data access request is authorized.

[0018] In other embodiments, the database is one of a plurality of databases used to receive the data. Each of the plurality of databases includes one of a plurality of ingress gates (GWs) and one of a plurality of egress gates (GWs), and the controller is used to select the database from the plurality of databases. This embodiment provides a multi-tiered system that can be used to improve the performance and reliability of the system. In other embodiments, the ingress gate is used to send the encrypted data to the database for storage by sending the data to a data distribution center. This embodiment can improve the system's performance when sending data to the database by managing the database more efficiently. In other embodiments, the controller authenticates the data provider through an authentication center. This embodiment can improve security by using an external authentication center separate from the system to authenticate users. In other embodiments, authorization for the data access request is granted by the data provider. This embodiment allows the data provider to control who is authorized to access the data.

[0019] According to an embodiment of the present invention, a method for storing data in a network database is provided. The method includes: an ingress gateway (GW) receiving a data upload request. The method further includes: a controller authenticating the data upload request. The method further includes: the ingress GW receiving uploaded data. The method further includes: the ingress GW performing data classification on the uploaded data, and the ingress GW encrypting the uploaded data. The method further includes: the ingress GW sending the uploaded data to the database. This embodiment is used to separate data storage services from access control services. This allows these two services to be provided by different entities, and makes the database service provider unaware of the data stored therein. In other embodiments, the uploaded data is encrypted by the ingress GW using the data classification, the ingress GW's hardware protection key, and a first cryptographic key calculated by the ingress GW based on a second key negotiated between the ingress GW and the provider of the uploaded data. This embodiment is used to ensure secure communication between the provider of the uploaded data and the system.

[0020] In other embodiments, the first cryptographic key is calculated based on the classification of the uploaded data. This embodiment can be used to provide a security level customized based on the characteristics of the data. Other embodiments include: the entry GW decrypts the data using a second key before encrypting the data using the first cryptographic key. This embodiment can improve security by encrypting the uploaded data twice before sending it to the database provider.

[0021] According to an embodiment of the present invention, a method for requesting data from a network database is provided. The method includes: an egress gateway (GW) receiving a data access request for data stored in the database. The method further includes: a controller authenticating the data access request. The method further includes: the controller receiving authorization for the data access request from the data provider. The method further includes: the egress GW receiving the data from the database and performing data classification on the data. The method further includes: the egress GW receiving a cryptographic key from the data provider. The method further includes: the egress GW decrypting the data using the cryptographic key. The method further includes: the egress GW providing the data requested in the data access request. This embodiment is used to separate data storage services from access control services. This allows these two services to be provided by different entities, and makes the database service provider unaware of the data stored therein. This embodiment is also used to enable the provider of uploaded data to control access to entities requesting access to uploaded data.

[0022] Other embodiments include: before completing the data access request, the egress GW decrypts the data using a third cryptographic key calculated by the egress GW based on the cryptographic key received from the data provider and the hardware protection key of the egress GW. This embodiment enables the provider of the uploaded data to control access to entities requesting access to the uploaded data. In other embodiments, the third cryptographic key is calculated based on the classification of the data. This embodiment can be used to provide a security level customized based on the characteristics of the data. In other embodiments, the data request is authenticated by the controller through an authentication center. This embodiment can improve security by using an external authentication center separate from the system to authenticate users.

[0023] According to embodiments of the present invention, an apparatus is provided, for example, implemented as an ingress gateway (GW). The apparatus includes a processor, at least one network interface, and a non-transitory machine-readable storage device (NMTD) storing machine-readable instructions, wherein the ingress GW is configured when the machine-readable instructions are executed by the processor. The ingress GW is configured to: receive a data upload request from a data provider, wherein the data upload request includes data; send the data upload request to a controller; receive a response corresponding to the data request from the controller; perform data classification on the data according to the response to obtain a classification result; generate a cryptographic key, wherein the cryptographic key is based on the classification result, a hardware protection key in the GW, and a key of the data provider; encrypt the data using the cryptographic key; and send the encrypted data to a database for storage. Advantageously, the database and the GW can be operated by different parties to enhance security and privacy. In other embodiments, the data received by the ingress GW is encrypted data from the data provider. In other embodiments, the ingress GW is further configured to decrypt the encrypted data from the data provider according to the key of the data provider to obtain decrypted data, wherein the data encrypted by the ingress GW is the decrypted data. In other embodiments, the ingress gateway (GW) is used to send the encrypted data to the database for storage via a data distribution center. In other embodiments, the response is an authentication from the data provider. In other embodiments, the ingress gateway (GW) and the controller are operated by the same party, which is different from the party operating the database.

[0024] According to embodiments of the present invention, an apparatus is provided, for example, implemented as an egress gateway (GW). The apparatus includes a processor, at least one network interface, and a non-transitory machine-readable memory storing machine-readable instructions, wherein the egress GW is configured when the machine-readable instructions are executed by the processor. The GW is configured to: receive a data access request from a data requester; send the data access request to a controller for authentication and authorization; receive a data instruction from the controller; perform data classification on the received data instruction to obtain a second classification result; receive data from a database associated with the data access request; generate a decryption key based on the second classification result, a hardware protection key of the egress GW, and the key of the data provider; decrypt the data based on the decryption key; and provide the decrypted data to the data requester. In other embodiments, the database and the GW are operated by different parties. In other embodiments, the egress GW is used to decrypt the data based on the decryption key and the key of the data provider. In other embodiments, the egress GW and the controller are operated by the same party, which is different from the party operating the database.

[0025] Embodiments have been described above in conjunction with various aspects of the present invention, and these embodiments can be implemented based on these aspects. Those skilled in the art will understand that embodiments can be implemented in conjunction with the aspects described therein, but may also be implemented together with other embodiments of that aspect. It will be apparent to those skilled in the art that embodiments are mutually exclusive or incompatible. Some embodiments may be described in conjunction with one aspect, but may also be applicable to other aspects, as will be apparent to those skilled in the art. Attached Figure Description

[0026] Further features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0027] Figure 1 This illustration shows the participants or entities provided in one embodiment of the invention and their roles in the PDAC system.

[0028] Figure 2 PDACaaS, which includes a PDAC service federation, is shown as an embodiment of the present invention.

[0029] Figure 3 This invention illustrates a PDAC system with a single-layer architecture according to an embodiment of the present invention.

[0030] Figure 4 This illustrates a hierarchical PDACaaS architecture provided by an embodiment of the present invention.

[0031] Figure 5 This illustrates a PDACaaS alliance architecture provided by an embodiment of the present invention.

[0032] Figure 6 The illustration shows a PDAC system that also includes an authentication center, provided by one embodiment of the present invention.

[0033] Figure 7 This invention illustrates a method for registering a data provider with a PDAC service provider, according to one embodiment of the present invention.

[0034] Figure 8 This invention illustrates a method for registering a data requester with a PDAC service provider, according to one embodiment of the present invention.

[0035] Figures 9A to 9D This invention illustrates a data uploading method for uploading data to a database in a PDAC system, according to an embodiment of the present invention.

[0036] Figures 10A to 10C This invention illustrates a data access method for accessing data stored in a database provider, according to an embodiment of the present invention.

[0037] Figure 11 This illustration shows a security-level-based data classification provided by an embodiment of the present invention.

[0038] Figure 12 This illustration shows a data classification based on data features provided by an embodiment of the present invention.

[0039] Figure 13A This illustration shows how to generate public-private key pairs for a data provider or data requester, according to one embodiment of the present invention.

[0040] Figure 13B The illustration shows an entry point GW for key generation when using a first-level encryption method, provided by an embodiment of the present invention.

[0041] Figure 13C An embodiment of the present invention illustrates an entry point GW that generates a key when using a two-level encryption method.

[0042] Figure 13D This invention illustrates an embodiment of the export GW that generates a key when using a two-level encryption method.

[0043] Figure 13E This invention illustrates an embodiment of the export GW that generates a key when using a two-level encryption method.

[0044] Figure 14 This is a block diagram of a computing system for implementing a PDAC system according to an embodiment of the present invention.

[0045] It should be noted that similar features are identified by similar reference numerals throughout the accompanying drawings. Detailed Implementation

[0046] This invention discloses methods, apparatus, and systems for providing a DBaaS that protects and enhances the privacy of data providers and includes authentication and access control for data stored in one or more databases or other storage systems. The embodiments provide "privacy database access control (PDAC)" and provide PDAC as a service (PDACaaS) to data providers, data requesters, database providers, and DBaaS service providers. The embodiments can support multiple levels of data privacy or security, including selectable or customizable protection levels. This invention also supports multiple PDAC service architectures, multiple cryptographic (encryption and decryption) schemes, and multiple data privacy process options. The embodiments separate the database provider's data storage responsibility from data access control to avoid data storage and access control being handled by a single provider. This separation provides a more secure system known to both data providers and data requesters, enabling a more secure and trusted data storage environment.

[0047] Figure 1 This illustration depicts the parties or entities involved in a PDAC system 100 provided according to one embodiment of the present invention and their roles. The PDAC system 100 is managed and controlled by a separate entity referred to herein as PDAC service provider 108. PDAC service provider 108 performs access control over database service provider 106 and database 112. In this embodiment, database service provider 106 may have access to one or more databases 112. The terms "database service provider" and "database provider" are used interchangeably when only a single database is accessed. To prevent database service provider 106 from accessing data stored in database 112 without authorization, PDAC service provider 108 may be a separate entity from database service provider 106. Therefore, for enhanced security, PDAC service provider 108 should not provide database services, and database service provider 106 should not be PDAC service provider 108.

[0048] Data Provider 102, or simply Provider, is a client of the PDAC service. Data Provider 102 can be an individual who owns proprietary data or data that Data Provider 102 is authorized to provide and share. Data Provider 102 can be the owner of one or more computing devices that create or store private data. In embodiments, the computing device can be a mobile device, such as a cellular phone. Data Provider 102 can also be an organization that owns its own private data. Data Provider 102 uses PDACaaS to upload and securely store proprietary data, and uses the PDAC service to control and manage access to and use of its data by others. Examples of Data Provider 102 are government departments that store citizen identity information or medical laboratories that store patient test results or medical histories. Individuals may use the PDAC service to store their financial data or other personal information. In these examples, Data Provider 102 may need to allow third parties access to some or all of its data. In other cases, legal authorization may be required for a third party to access the data. Third-party access to partially anonymized data, such as compiled health statistics, may also be required. Embodiments provide mechanisms for notifying Data Provider 102 whether it has requested or demanded access to its data.

[0049] Data is stored in multiple independent or affiliated privacy databases 112. Database service provider 106 provides databases 112 within the PDAC system to store proprietary data of data provider 102. These data providers 102 should be different from PDAC service provider 108 to ensure that data stored in databases 112 cannot be accessed by database service provider 106. In this embodiment, database provider 106 cannot access unencrypted or decrypted data and is unaware of the content of the data stored therein. Databases 112 can use various underlying technologies. Database 112 can be a relatively simple network-attached storage, remote server, or cloud storage. Database 112 can also be a complex relational database with large storage capacity, robust backup facilities, and fast access. Each database 112 can provide database information, including parameters, to database service provider 106 or PDAC service provider 108 regarding the location, capabilities, and operating parameters of each database 112. This database information may include, but is not limited to, the database's storage capacity, supported programming languages, and the database's location or address.

[0050] Data is obtained from database service provider 106 by one or more data requesters 104. Data requester 104 is an individual or organization wishing to access proprietary data of data provider 102. In this embodiment, access to data is authorized by data provider 102 or through legal means. Examples of data requesters 104 are authorized government entities, healthcare providers of data provider 102 (e.g., doctors or dentists), or parties designated by data provider 102. Data requester 102 can access the data online or offline. Online access means that data requester 104 can only remotely access and process the data stored in PDAC system 100. Offline access means that data requester 104 can download the data and process it locally. Other access methods and hybrid online and offline access may also be used.

[0051] In this embodiment, data provider 102 may be represented by agent 110. If a certain level of mutual trust has been established between data providers 102, or if it is agreed that agent 110 represents data provider 102, then the agent of data provider 102 can perform the required data processing on behalf of data provider 102. Generally, a data provider may include a data owner or an agent. In some embodiments, only the data owner can provide authorization. In other embodiments, the data provider can provide authorization, and the data provider is either the data owner or an agent.

[0052] like Figure 2 As shown, PDAC service provider 108 can be combined with database service provider 106 and its various databases 112 to form PDAC service alliance 202 to provide PDACaaS. In an embodiment, Figure 3 The PDAC controller 302 in the middle can communicate with third-party authentication, authorization, and accounting (AAA) entities (e.g., Figure 6 The authentication center (602) performs authentication and authorization actions. The authentication center (602) can be part of the core network (CN) of the cellular wireless network.

[0053] The PDAC service architecture can utilize many variations, including single-tier architecture, two-tier hierarchical architecture, and PDAC service federation architecture, as described below.

[0054] Figure 3 A single-tier architecture provided in one embodiment is illustrated. In this embodiment, a PDAC controller 302, an ingress gateway (GW) 306, and an egress gateway (GW) 310 have been added. Figure 2In this architecture, the ingress GW 306 and egress GW 310 can be controlled by the PDAC service provider 108, but in other cases, the ingress GW and egress GW can be controlled by different entities. Additionally, the architecture can provide a data distribution center 308 and a log server 304. The data distribution center 308 can be controlled by different providers such as the PDAC service provider 108, the database service provider 106, or a third party. The log server 304 can be controlled by either the PDAC service provider 108 or the database service provider 106. The log server 304 communicates with the data distribution center 308 and the egress GW 310.

[0055] The ingress GW 306 connects to data provider 102 (or their agent 110) to receive uploaded data provided by data provider 102. The ingress GW 306 can also be used to hide the identity of data provider 102 or its agent 110 from database provider 106, thereby providing anonymity for data provider 102 and enabling anonymous data uploads. The ingress GW 306 can also improve network performance between data provider 102 and database 112 by using techniques known in the art such as proxies and buffers. The ingress GW 306 can be dedicated to a single data provider 102 or a group of data providers, or it can serve a specific geographic area. The ingress GW 306 also connects to an optional data distribution center 308, which in turn connects to one or more databases 112 provided by database service provider 106 for data storage. The ingress GW 306 includes control and data processing functions.

[0056] The export GW 310 connects database 112 to data requester 104 to forward data to requester 104. The export GW 310 can also be used to hide the identity of data requester 106 from database provider 106. The export GW 310 can also improve network performance between data provider 102 and database 112 by using techniques known in the art such as proxies and buffers. The export GW 310 can be dedicated to a single data provider 102 or a group of data providers, or it can serve a specific geographic area. The export GW 310 also connects to log server 304 for more efficient data access. The export GW 310 includes control and data processing functions. The export GW 310 can be scaled to include sufficient computing resources to enable data requester 104 to perform online data processing, where data is not transmitted to data requester 104.

[0057] The control interfaces between components in a PDAC system, such as Figure 3As shown by the dashed lines, the PDAC service provider 108 operates the PDAC controller 302. The PDAC controller 302 may have control interfaces connected to the data provider 102 or its agent 110, ingress GW 306, egress GW 310, and data requester 104. The log server 304 may have control interfaces connected to the data distribution center and egress GW 310. Other control interfaces, not shown, may also exist as needed.

[0058] PDAC service elements can be implemented in various ways, including as discrete computing systems or as network slices, which include... Figure 3 The diagram shows the components and their interconnections. Network slicing refers to a technique for creating virtual networks that separate different types of network traffic and can be used in reconfigurable network architectures, such as those employing Network Function Virtualization (NFV). A network slice comprises a collection of logical network functions that support communication service requirements for specific scenarios. Logical network functions can be instantiated on network hardware, including servers, routers, etc. Network slicing also includes the necessary links between network functions that allocate bandwidth to meet Quality of Service (QoS) and Quality of Experience (QoE) requirements.

[0059] In embodiments, various parts of the PDACaaS architecture can be implemented as virtual network functions. In some cases where network access is via a cellular wireless network, the entities communicating with data provider 102 and data requester 106 (e.g., ingress GW 306 and egress GW 310) can be implemented in the radio access network (RAN) portion of the network. This can be advantageous when data provider 102 or data requester 106 is a cellular mobile device or user equipment (UE).

[0060] Figure 4 This illustration shows a layered PDACaaS architecture provided by an embodiment of the present invention. The layered PDACaaS architecture may include a multi-tiered PDAC service federation, for example... Figure 4The two-tier PDAC service consortium 400 shown includes first-tier consortia 404a and 404b and a second-tier consortium 402. Each first-tier consortium 404a and 404b includes multiple database providers 106a and 106b, each database provider having its own ingress GW 306a and 306b, data distribution centers 308a and 308b, egress GW 310a and 310b, and log servers 304a and 304b. The second-tier consortium 402 includes an ingress GW 406 and an egress GW 410, such that the two-tier PDAC service consortium 400 appears to either data provider 102 or data requester 104 as... Figure 3 The single-tier architecture 202 shown is as follows. It is understood that within each first-tier federation, the number of databases 112 and the number of database providers 106a and 106b can be increased to any number to take into account performance-related factors such as load balancing, latency, geographic location, redundancy, etc., and the tiers of ingress GWs 406, 306a, and 306b and egress GWs 410, 310a, and 310b can be increased.

[0061] Figure 5A PDACaaS alliance architecture provided by an embodiment of the present invention is illustrated. The PDACaaS alliance architecture 500 may include one or more service consortia 504a and 504b, as shown in the figure. Each service consortium may include at least one PDACaaS provider, such as 108a and 108b. The PDACaaS providers within the architecture 500 may form an alliance, which may be referred to as a "PDAC Alliance" or a "PDAC Service Alliance". The PDAC Alliance includes an interface 502 that enables communication and cooperation among multiple PDACaaS providers 108a and 108b to perform various actions more efficiently, such as data requests, approval requests, record sharing, etc. Accordingly, PDACaaS providers 108a and 108b may communicate and cooperate together to respond to data provider 102a or 102b's requests to upload data from data requesters 104a and 104b, access uploaded data, and so on. In some embodiments, the PDAC alliance may also include one or more of data providers 102a and 102b, their agents 110a or 110b, and data requesters 104a or 104b as members of the PDAC service alliance. It is understood that the number of PDAC service alliance members 504a and 504b can be increased to any number to take into account performance-related factors such as load balancing, latency, geographic location, redundancy, etc. Furthermore, large-scale PDAC service alliances can also be implemented where each participating organization has its own PDAC service provider. It is also understood that the multi-tier architecture 400 can be combined with the alliance architecture 500 to create a more complex PDACaaS architecture depending on the needs or expectations of a specific implementation.

[0062] Different PDACaaS architectures can be used to achieve different levels of security. Due to redundancy between database service providers 404a and 404b, as well as ingress and egress gateways, the multi-tier architecture 400 offers higher reliability and performance than the single-tier architecture 300. The federated architecture 500 enables even more secure operations because different PDAC service providers 108a and 108b can provide customer security and services to different types of data providers 102a and 102b, as well as different types of service requesters 104a and 104b.

[0063] PDAC service provider 108 provides various services and performs multiple actions to provide PDACaaS. PDAC service provider 108 is responsible for deploying PDAC controller 302. Deploying PDAC controller 302 may include instantiating network slices and virtual machines, activating or enabling the controller, and deploying the required number of PDAC controllers for the selected PDACaaS architecture.

[0064] Conversely, the PDAC controller 302 is responsible for registering and authenticating the data provider 102, and controlling the data upload of the data provider 102 or its agent 110. The PDAC controller 302 is also responsible for registering and authenticating the data requester 104, and controlling the data access of the data requester 104.

[0065] PDAC controller 302 is responsible for deploying or instantiating any ingress GW 306 or egress GW 310 as required by the PDACaaS architecture. Deploying ingress GW 306 provides sufficient interfaces to data provider 102 or its agent 110, as well as to data distribution center 308. Ingress GW 306 controls data uploading, including data classification and control of keys used for data encryption.

[0066] As used in this document, "cryptographic key" can be simply referred to as a key and includes both encryption and decryption keys. An encryption key is a cryptographic key used to encrypt data. A decryption key is a cryptographic key used to decrypt data. Both encryption and decryption keys can be part of a pair of cryptographic keys, such as a public-private key pair or a symmetric key, as known in the art.

[0067] PDAC controller 302 is responsible for deploying or instantiating any data distribution center 308 to control the data distribution among databases 112.

[0068] PDAC controller 302 is responsible for deploying or instantiating any egress GW 310 to control access to data stored in database 112, including data classification, controlling encryption and decryption, online and offline data access, and connecting to data requester 104 and log server 304. Egress GW 310 can also be extended to connect to cloud computing resources used when data requester 104 can only access data online.

[0069] Each database service provider 106 may determine or specify whether to deploy, instantiate, and manage any log servers 304 required for its database 112. Database service provider 106 also provides and manages the database 112 for storing data and deploys database controllers to connect to ingress GW 306, egress GW 310, or any controller of either ingress GW 306 or egress GW 310.

[0070] Figure 6 The illustration shows a PDAC system that also includes an authentication center, provided by one embodiment of the present invention. Figure 6 The PDAC system 600 in the middle can be similar to Figure 3The PDAC system 300 is modified, but a certification authority 602 is added. As described herein, in some embodiments, the PDAC controller 302 can perform authentication and authorization actions with a third-party AAA entity (such as the certification authority 602, which is further discussed herein).

[0071] In this embodiment, the data provider 102 or the data requester 104 must register with the PDAC service provider 108 in order to use PDACaaS. Figure 7 This illustration shows a method for registering a data provider 102 to a PDAC service provider 108 according to an embodiment of the present invention. In step 701, the data provider 102 sends a provider registration request to the PDAC controller 302. The registration request 701 may include one or more parameters (e.g., data provider client ID) and a method for sending a registration request to a certification authority 602 (e.g., a PDAC service provider 102). Figure 6 (As shown) Authentication contact information (e.g., certificate or address). In step 702, PDAC controller 302 can use the contact information to forward the provider registration request to ID authentication center 602. In some embodiments, PDAC controller 302 can use ID authentication center 602 known to the PDAC system, or determine ID authentication center 602 by other means. In step 703, if ID authentication center 602 successfully authenticates data provider 102, PDAC controller 302 can register data provider 102 and can allocate or generate encryption keys, such as public-private keys, to communicate with data provider 102 and PDAC controller 102, thereby retaining the private key and client ID. PDAC controller 302 can also generate authentication parameters, such as PDAC certificates, or instructions authorizing the data provider to receive PDAC services. In step 704, PDAC controller 302 sends a provider registration response to data provider 102. The provider registration response may include one or more parameters, such as a public key generated for communication between the PDAC controller 302 and the data provider 102, a list of entry GW 306, and public keys and authentication parameters required for communication with the entry GW 306. In some embodiments, the encryption key used by the data provider 102 may be transmitted via a secure channel. In step 705, the data provider 102 receives the provider registration response and stores the public key used for encrypting communication with the PDAC controller 302, the public key used for communicating with the entry GW 306, the authentication parameters, and its own public-private key pair. The PDAC controller 302 updates its own list of registered data providers. In embodiments where the agent 110 represents the data provider 102, the agent 110 may perform the actions of the data provider 102 as described above.

[0072] Figure 8This invention illustrates a method for registering a data requester 104 to a PDAC service provider 108 according to an embodiment of the present invention. In step 801, the data requester 104 sends a requester registration request to the PDAC controller 302. The registration request may include one or more parameters (e.g., the data requester client ID) and contact information (e.g., a certificate or address) for contacting the authentication center 602. In step 802, the PDAC controller 302 may use the contact information to forward the requester registration request to the ID authentication center 602. In some embodiments, the PDAC controller 302 may use an ID authentication center 602 known to the PDAC system, or determine the ID authentication center 602 by other means. In step 803, if the ID authentication center 602 successfully authenticates the data requester 104, the PDAC controller 302 may register the data requester 104 and may allocate or generate encryption keys, such as public-private keys, to communicate with the data requester 104 and the PDAC controller 102, which retains the private key and client ID. PDAC controller 302 can also generate authentication parameters, such as PDAC certificates, or instructions to authorize a data requester to receive PDAC services. In step 804, PDAC controller 302 sends a requester registration response to data requester 104. The requester registration response may include one or more parameters, such as a public key generated for communication between PDAC controller 302 and data requester 104, a list of exit GW 310, and the public key and authentication parameters required for communication with exit GW 310. In some embodiments, the encryption key used by data requester 104 can be transmitted via a secure channel. In step 805, data requester 104 receives the requester registration response and stores the public key used to encrypt communication with PDAC controller 302, the public key used to communicate with exit GW 310, the authentication parameters, and its own public-private key pair. PDAC controller 302 updates its own list of registered data requesters.

[0073] Figure 9 includes Figures 9A to 9DThis illustration shows a data upload method 900 for uploading data to database 112 according to an embodiment. The data upload method 900 may include single-layer encryption of the data by data provider 102 and entry GW 306, and double-layer encryption of the data by data provider 102 and entry GW 306. Before executing the data upload method 900, data provider 102 has registered with the PDAC service and obtained its own and a list of encryption keys for entry GW 306, as well as the public key of entry GW 306. Entry GW 306 is also pre-configured with the required encryption keys. These encryption keys may be hardware-protected and cannot be altered. In step 901, data provider 102 sends an upload request to entry GW 306. The data upload request may include parameters such as the client ID of data provider 102, authentication materials, and PDAC service preferences, so that the PDAC system classifies the data and assigns a security protection level to be used with the uploaded data. In step 802, the ingress GW 306 sends the received upload request and the parameters received in the upload request to the PDAC controller 302. In step 903, the PDAC controller 302 verifies the identity of the data uploader 102 and generates an authentication identifier. In step 904, the PDAC controller 302 sends an upload response to the ingress GW 306. The upload response may include one or more parameters, such as the client ID of the data provider 102, the authentication identifier generated in step 903, and configuration information for the PDAC service, such as a list of security protection levels supported by the PDAC system. In step 905, the ingress GW 306 performs authentication using the authentication materials from the upload request and the authentication identifier generated by the PDAC controller 302 in step 903. If authentication is successful, the ingress GW 306 configures the PDAC service for the data provider 102.

[0074] Figure 9B This illustrates a first option using primary encryption provided by an embodiment of the invention. In step 906, a session key and token (SK) are negotiated between data provider 102 and ingress GW 306 using existing methods such as Diffie-Hellman (DH) key exchange. tk The token generated in step 906 is valid only for the duration of the session in which the token was generated. In step 908, data provider 102 sends a client key transfer message to ingress GW 306. The client key transfer message may include the key (K) of data provider 102. client The key is encrypted using the session key generated in step 906. The client key transmission message may also include data to be uploaded to the ingress GW 306, which can be transmitted using SK. tk or K clientEncryption is performed. In step 910, the entry point GW 306 classifies the data and calculates the encryption key (which can be called the cryptographic key) K. ingress And using K ingress Uploaded data is encrypted and processed from data provider 102. Finally, entry point GW 306 can destroy K. client To avoid accessing K that has already been used client Data that has been encrypted.

[0075] Figure 9C This illustrates an embodiment of the invention that uses secondary encryption instead of... Figure 9B The second option for primary encryption is shown in steps 906, 908, and 910. Using the second option, in step 912 following step 910, ingress GW 306 sends a response to data provider 102. The response can serve as an acknowledgment and include an authentication result. This response can indicate... Figure 9A The authentication result in step 905. In step 914, data provider 102 sends the uploaded data and its data characteristics, classification, or description to ingress GW 306. The uploaded data uses the client's key K. client Encryption is performed. In step 916, the entry point GW 306 classifies the uploaded data and calculates the encryption key K. ingress and using K ingress The data was re-encrypted. Therefore, the uploaded data was encrypted twice; the first encryption was performed by data provider 102 using K... client Encryption is performed, and the second encryption is performed by the entry point GW 306 using K. ingress Encrypt it.

[0076] Figure 9D The steps performed after encryption by ingress GW 306 are shown. In step 918, ingress GW 306 sends a request to data distribution center 308 using option 1 (… Figure 9B ) or option 2 ( Figure 9C The data is encrypted, and data classification information is also processed. In step 920, the data distribution center 308 transmits the encrypted data to the privacy database 112. In step 922, the data distribution center 308 sends a status update message to the log server 924. The status update message may include one or more parameters, such as the client ID of the data provider 102, the database address, and data classification information. Finally, in step 924, the log server 304 stores the updated status message therein.

[0077] Figure 10 includes Figures 10A to 10CThis illustration shows a data access method 1000 provided in one embodiment for accessing data stored in a database provider 106. The data access method 1000 provides options for online data access and offline data access. Figure 10A In step 1001, the previously registered data requester 104 sends a data access request to the PDAC controller 302. The data access request may include one or more parameters, such as the data requester 104's ID, the ID of the known data provider 102, data characteristics or data description, a description of any use of the accessed data, and whether the data requester 104 wishes to use an online or offline data access process. In step 1002, the PDAC controller 302 verifies the data requester 104 and determines the exit GW 310 that the data requester 104 can access. In step 1003, the PDAC controller 302 sends a data access approval request to the data provider 102 or its agent 110 that uploaded or possesses the data mentioned in the data access request received in step 1001. The data access approval request may include one or more parameters, such as the data provider 102's client ID, the data requester 104's ID, any use of the accessed data, data characteristics or data description, the pending ID of the exit GW, or the pending address of the exit GW 310, etc. The data access approval request may also include the public key for the export GW 310. If data provider 102 approves the data access approval request, then in step 1004, data provider 102 generates a session key and a token SK. tk In step 1005, data provider 102 sends a data access approval response to PDAC controller 302. The data access approval response may include one or more parameters, such as SK encrypted using the public key of export GW 310. tk SK tk It can also be used for K client Encryption is performed. In step 1006, the PDAC controller 302 sends a data access response to the data requester 104. The data access response may include one or more parameters, such as the ID of the data provider 102 and the ID or address of the export GW 310 and its public key. In step 1007, the PDAC controller 310 sends a data access indication message to the export GW 310. The data access indication message may include one or more parameters, such as the ID of the data requester 104 and its public key, and the SK encrypted using the public key of the export GW 310. tk Data characteristics or data description, data provider 102's ID, and any data processing preferences.

[0078] Figure 10BThis is a continuation of the data access method 1000 provided in one embodiment of the present invention. In step 1008, the egress GW 310 uses data features derived from uploaded data to classify and assign data to the requested data. In step 1009, the egress GW 310 sends a database address request to the log server 304. The database address request 1009 may include one or more parameters, such as the ID of the data provider 102, or a data classification value. In step 1010, the log server 304 responds to the database address request by sending a data address response to the egress GW 310. The data address response may include one or more parameters, such as the ID of the data provider 102, the address of the database, its location, or the address of the data stored in the database. In step 1011, the egress GW 310 retrieves data from one or more databases storing the data. In step 1012, the egress GW 310 sends a client key request to the data provider 102. The client key request may include a request for a client key. In step 1013, data provider 102 responds to the client key request using a client key transmission message sent by data provider 102 to the egress GW310. The client key transmission message may include one or more parameters, such as data provider 102's encryption key (also referred to as a second key) K. client The key uses SK tk Encryption is performed. When SK tk Expired, SK tk When invalid, K client It may be destroyed, at which point K client Decryption may no longer be required.

[0079] Figure 10C This is a continuation of the data access method 1000 provided in one embodiment of the present invention. In step 1014, the output GW 310 calculates an encryption key (which may be called a cryptographic key) K for decrypting the requested data. egress To process the requested data, destroy the SK token. tk K client Then generate a new session key and token SK. tk_re To use SK tk_re The requested data is encrypted. In step 1015, the export GW 310 sends an SK encrypted using the public key of the data requester 104 to the data requester 104. tk_re .

[0080] If the requested data is processed online without being transmitted to the data requester 104, in step 1016, the export GW 310 can process the data online according to the data processing preferences of the data requester 104. Once the export GW 310 processes the data online, it can send a report or summary to the data requester 104. If the requested data is processed offline by transmitting it to the data requester 104, in step 1017, the export GW 310 can send a report or summary to the data requester 104 using SK. tk_re The requested data is encrypted. In some embodiments, a combination of online and offline processing can be used, in which case steps 1016 and 1017 can be performed. Finally, in step 1018, the data requester 104 can encrypt the data according to SK. tk_re Destroy data. When SK tk_re Expired, SK tk_re When the data fails, it may be destroyed, and in this case, it may no longer be decrypted.

[0081] The implementation can be customized for PDACaaS to support a variety of different applications and clients. The implementation includes various PDAC service architectures, various data encryption and decryption methods, and various options for the data requester 104 to process the requested data.

[0082] Customization of the PDAC service allows PDACaaS implementations to meet the needs of a wide range of clients, such as data provider 102 and data requester 104. Clients can select or define service parameters to customize PDACaaS based on their specific service requirements and the type or characteristics of the data they use. Some examples of data types or characteristics are identification (ID) files or ID-related data, personal health-related data or files, personal or business investment data, social relationship files such as contact information data, and personal or business financial or billing information.

[0083] Each provided PDAC service can serve multiple data providers 102 or data requesters 104. Each data provider 102 can customize the preferred data protection level to receive from the PDAC service. A set of data protection levels can be specified for a specific type of data. A set of data protection levels can include parameters such as architecture, encryption scheme, or privacy. The architecture can include a layered PDACaaS architecture 400, a PDACaaS consortium architecture 500, or a hybrid of different architectures. The encryption (or cryptographic) key parameter can define the keys used for data encryption and decryption, or define whether a single-layer encryption scheme or a two-layer encryption scheme is used. The privacy parameter can select online or offline access for some or all of the data being accessed.

[0084] For example, for highly sensitive data such as identity documents managed by government entities, a set of data protection levels could include a two-tiered PDACaaS architecture, a two-layer encryption scheme, and online access only. For less sensitive data, such as personal investment records, a set of data protection levels could include a single-tiered architecture (300) and allow offline access for the data requester (104).

[0085] Data provider 102 can select its preferred PDAC service based on the capabilities of available PDAC services. Data provider 102 can request specific characteristics and parameters as part of the data upload method 900, specifically as part of the upload request received in step 901. PDAC controller 302 can also determine the parameters of data provider 102 based on the protection level requirements, data type, etc., sent by the client in the upload request in step 901.

[0086] In the field of data management, data classification, which falls under the information lifecycle management process, can be used as a tool to enable or assist PDAC service providers or database providers in determining which baseline security controls are appropriate for protecting data. Each data provider 102 or data requester 104 may have its own classification, and may also have classification criteria defined according to industry or organization type (e.g., commercial or government). Data classification can include security levels and data characteristics or types.

[0087] Figure 11 This illustrates a security-level-based data classification provided by an embodiment of the present invention. For example... Figure 11 As shown, the security levels corresponding to different categories of commercial data 1102 can include sensitive, confidential, private, proprietary, and public. The security levels of government data 1104 can include top secret, confidential, secret, sensitive, and non-confidential.

[0088] Figure 12 This illustrates a data classification based on data features provided by an embodiment of the present invention. For example... Figure 12 As shown, the data types used for commercial data 1102 may include business data, personal data, social data, health data, environmental data, etc. The data types for government data 1104 may include personally identifiable data, military data, police or legal data, community data, etc. Other categories, security levels, etc., can be added or defined as needed. In this embodiment, the PDAC service can support any number of standards for classifying data, and these standards can be pre-configured in the ingress GW 306 or egress GW 310.

[0089] The embodiments provide lifecycle management for encryption keys used in a PDAC system. Specifically, the PDAC system can support and manage public-private key pairs, database encryption keys, and temporary session keys with restricted use and tokens.

[0090] After registering with the PDAC system, data provider 102 or data requester 104 can have their own public-private key pair or the PDAC system's public key. Ingress GW 306 or egress GW 310 can also have their own public-private key pair or the PDAC system's public key. Similarly, the PDAC system can store the public keys of system entities (e.g., data provider 102, data requester 104, ingress GW 306, or egress GW 310). These public-private keys are used to sign or encrypt messages or negotiate session keys. In some embodiments, system entities can store private keys protected by secure hardware. Public-private key pairs can also be set to expire after a predetermined time, or based on criteria or events (e.g., detection of a hacking attack).

[0091] Figure 13A This illustration shows how, in one embodiment, a public-private cryptographic key pair is generated for a data provider 102 or a data requester 104. In 1302, the client or its agent can provide initial parameters (e.g., a password or master key) by inputting these parameters into a key derivation function (KDF). In 1304, the client key K is obtained. client It can be used to encrypt data and messages. The initial parameters are known only to the client, and the private key can only be stored on the client's own hardware. The K key will be revoked later. client To avoid using tokens to access data. Self-destructing data can also be achieved using technologies such as Self-Destructing Data System (SeDaS), Vanish systems, or similar techniques. Data self-destruction can be controlled by a token value, which can be assigned by the data provider 102, their agent 110, or the PDAC system. Once the token value expires, K... client Once destroyed, the data may not be easily decrypted. This feature allows data provider 102 to regain control of or revoke their data access.

[0092] The implementation includes a database encryption key to prevent database provider 106 from accessing unencrypted data stored in the PDAC system. To enhance security, especially when database service provider 106 could be a cloud computing provider, the database encryption key has a time expiration period, which may depend on the duration of data expected to be stored in database 112 and the duration of data access by data requester 104. For example, the encryption key's time expiration could be set to two years if authorized data requester 104 or other entity has access to the database for two years. The longer the encryption key's time expiration, or if it does not expire, the more secure the key.

[0093] In this embodiment, the data encryption key can be generated by the entry point GW 306, such as... Figure 13B As shown. The entry point GW 306 can use a KDF with the following inputs: K0, where K0 is a hardware protection key specific to the entry point GW 306 and can be stored in the hardware security module (HSM) of the entry point GW 306; K client The second key of data provider 102; a value derived from the classification of data received from data provider 102, wherein the value is determined by entry GW 306.

[0094] Figure 13B A first-level encryption method for sending data received from data provider 102 to database 112, according to an embodiment of the present invention, is also shown. First, the ingress GW 306 receives data from data provider 102 using data provider 102's K... client The data is encrypted. In 1310, the entry GW 306 uses K. client The received data is decrypted. In step 1312, entry point GW 306 determines the classification of the decrypted data. In step 1314, within the KDF of entry point GW 306, the data classification is correlated with the KDF specific to entry point GW 306 itself. client Combined with K0, it generates a cryptographic (encryption) key pair K. ingress In 1316, the entry GW 306 uses K. ingress The data used for transmission is encrypted. Finally, in 1318, K is destroyed. client To avoid further use of K client .

[0095] Figure 13C This illustration shows a secondary encryption method for sending data received from data provider 102 to database 112, according to an embodiment of the present invention. In 1320, entry GW 306 acquires a data classification. In 1322, in the KDF of entry GW 306, the data classification is associated with a KDF specific to entry GW 306 itself.client Combined with K0, it generates a cryptographic (encryption) key pair K. ingress In 1324, the entry GW 306 uses K. ingress Encrypt the data used for transmission.

[0096] Figure 13D This illustration shows a two-level decryption method for sending data received from database 112 to data requester 104, according to an embodiment of the present invention. In step 1330, the exit GW 310 acquires the data classification. In step 1332, in the KDF of the exit GW 310, the data classification is associated with K0 and the second key K. client Combine to generate a cryptographic (decryption) key pair K egress Here, K0 is a hardware protection key specific to the export GW 310 itself. In 1334, the export GW 310 uses K... egress The data is decrypted once. Then, in 1336, the export GW 310 uses K. client The data is decrypted again before being sent to the data requester, 104. Finally, in 1338, K is destroyed. client To avoid further use of K client .

[0097] Figure 13E This illustration shows a first-level decryption method for sending data received from database 112 to data requester 104, according to an embodiment of the present invention. In 1340, the egress GW 310 acquires a data classification. In 1342, in the KDF of the egress GW 310, the data classification is associated with a K0 specific to the egress GW 310 itself and a second key K. client Combine to generate a cryptographic (decryption) key pair K egress In 1344, the export GW 310 uses K received from the inlet GW 306. egress The data is decrypted before being sent to the data requester, 104. Finally, in 1346, K is destroyed. client To avoid further use of K client .

[0098] A temporary session key can be negotiated between the exit GW 306 and the data requester 104, or between the data provider 102 and the ingress GW 306, to encrypt the data. This session key can be encrypted using a public key.

[0099] Figure 14This is a block diagram of a computing system 1400 that can be used to implement the devices and methods disclosed herein. A specific device may use all of the components shown or only a subset of these components, and the degree of integration of the devices may vary. Furthermore, the device may include multiple instances of components, such as multiple processing units, multiple processors, multiple memories, multiple transmitters, multiple receivers, etc. The computing system 1400 includes a processing unit 1402. The processing unit 1402 typically includes a central processing unit (CPU) 1405, a bus 1410, and memory 1415, and may optionally include a mass storage device 1420, a video adapter 1425, and an I / O interface 1430 (as shown by dashed lines).

[0100] CPU 1405 may include any type of electronic data processor. Memory 1415 may include any type of non-transitory system memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or combinations thereof. In one embodiment, memory 1415 may include ROM used at power-on and DRAM storing programs and data used during program execution. Bus 1410 may be one or more of several types of bus architectures, including a memory bus or memory controller, a peripheral bus, or a video bus.

[0101] Mass storage 1420 may include any type of non-transitory storage device for storing data, programs, and other information and making such data, programs, and other information accessible via bus 1410. Mass storage 1420 may include, for example, one or more of solid-state drives, hard disk drives, disk drives, and optical disk drives.

[0102] Video adapter 1425 and I / O interface 1440 provide optional interfaces to couple external input and output devices to processing unit 1402. Examples of input and output devices include a display 1435 coupled to video adapter 1425 and I / O device 1440 (e.g., a touchscreen) coupled to I / O interface 1430. Other devices may be coupled to processing unit 1402, and more or fewer interfaces may be used. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for external devices.

[0103] Processing unit 1402 may further include one or more network interfaces 1450, which may include wired links such as Ethernet cables or wireless links connecting to one or more networks 1445. Network interfaces 1450 enable processing unit 1402 to communicate with remote entities via network 1445. For example, network interface 1450 may provide wireless communication via one or more transmitter / transmit antennas and one or more receiver / receive antennas. In one embodiment, processing unit 1402 is coupled to a local area network (LAN) or wide area network (WAN) for data processing and communication with other processing units, the Internet, or remote storage facilities.

[0104] Based on the description of the above embodiments, the present invention can be implemented solely in hardware, or it can be implemented using software and a necessary general-purpose hardware platform. Based on this understanding, the technical solution of the present invention can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transient storage medium, such as a compact disk read-only memory (CD-ROM), a USB flash drive, or a removable hard drive. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in the embodiments of the present invention. For example, such performance may correspond to the simulation of the logical operations described herein. According to embodiments of the present invention, the software product may additionally or optionally include multiple instructions that enable a computer device to perform operations configuring or programming digital logic devices.

[0105] Although the invention has been described with reference to specific features and embodiments thereof, it will be apparent that various modifications and combinations thereof can be made without departing from the invention. Therefore, the specification and drawings are to be regarded merely as a description of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations, or equivalents within the scope of the invention.

Claims

1. A system for providing network database services, characterized in that, The system includes: Controller, used for: Receive one or more data requests; Authenticate the one or more data requests; A gateway (GW) that communicates with the controller, wherein the GW is used for: Receive a response from the controller corresponding to at least one of the one or more data requests; Receive data from data providers; Based on the response, perform data classification on the data to obtain classification results; Generate a cryptographic key for accessing the database, wherein the cryptographic key is based on the classification result, the hardware protection key in the GW, and the key of the data provider, and the cryptographic key is used to encrypt the data; The GW and the controller are operated by the same party, which is different from the party that operates the database.

2. The system according to claim 1, characterized in that, The GW is an entry GW, and the one or more data requests include data upload requests. The entry GW is also used to: send the data upload request to the controller, encrypt the data according to the password key, and send the encrypted data to the database for storage.

3. The system according to claim 2, characterized in that, The one or more requests include data access requests from data requesters, and the controller is further configured to: perform authentication and authorization on the data access requests, and send data indications to the egress GW; the system also includes: the egress GW, configured to: The received data is instructed to be classified to obtain a second classification result; Receive data from the database; A decryption key is generated based on the second classification result, the hardware protection key of the export GW, and the key of the data provider; The data is decrypted using the decryption key, and the decrypted data is provided to the data requester.

4. The system according to claim 3, characterized in that, The export GW is used to decrypt the data based on the decryption key and the key of the data provider.

5. The system according to claim 3 or 4, characterized in that, The controller is configured to authorize the data access request by confirming to the data provider that the data access request is authorized.

6. The system according to claim 4, characterized in that, The controller is further configured to: send a data access approval request to the data provider, and receive a data access approval response from the data provider, wherein the data access approval request includes one or more of the following: the data provider's client identifier, the identifier of the data requester, the use of the data, data characteristics or data description, the identifier or address of the export GW, and the public key of the export GW; and the data access approval response includes a session key and token (SK) encrypted using the public key of the export GW. tk ), SK tk Generated by the data provider.

7. The system according to claim 4, characterized in that, The egress GW is also configured to receive an indication message from the controller, wherein the indication message includes an identifier of the data requester and the public key of the identifier, a session key and token (SK) encrypted using the public key of the egress GW. tk One or more of the following: data characteristics or data description, the identifier of the data provider, and the security level preference of the privacy database access control (PDAC) service.

8. The system according to claim 4, characterized in that, The controller is also configured to send a data access response to the data requester, wherein the data access response includes one or more of the data provider's identifier, the identifier or address of the egress GW, and the egress GW's public key.

9. The system according to claim 4, characterized in that, The export GW is also used for: Send a database address request to the log server, wherein the database address request includes one or more of the data provider's identifier and data classification values; Receive a data address response from the log server, wherein the data address response includes one or more of the following: the identifier of the data provider, the address of the database, the location of the database, and the address of the data stored in the database.

10. The system according to claim 4, characterized in that, The export GW is also used for: Send a client key request to the data provider; Receive a client key transmission message from the data provider, wherein the client key transmission message is a response to the client key request, and the client key transmission message includes the data provider's identifier and the data provider's key, session key, and token SK. tk One or more of the generated encryption keys.

11. The system according to claim 3 or 4, characterized in that, The inlet GW, the outlet GW, and the controller are operated by the same party, which is different from the party that operates the database.

12. The system according to any one of claims 2 to 4, characterized in that, The data received by the ingress GW is encrypted data from the data provider.

13. The system according to claim 12, characterized in that, The entry GW is also used to decrypt the encrypted data from the data provider according to the key of the data provider to obtain decrypted data, wherein the data encrypted by the entry GW is the decrypted data.

14. The system according to any one of claims 2 to 4, characterized in that, The system further includes a data distribution center, configured to: receive the encrypted data from the entry GW, select the database to store the encrypted data, and store the address of the database in a log server; the entry GW is configured to send the encrypted data to the database for storage through the data distribution center.

15. The system according to any one of claims 1 to 4, characterized in that, The controller is also used to authenticate the data provider through an authentication center.

16. A method executed by an ingress gateway (GW), characterized in that, The method includes: Receive a data upload request from a data provider, wherein the data upload request includes data; Send the data upload request to the controller; Receive the response corresponding to the data request from the controller; Based on the response, perform data classification on the data to obtain classification results; Generate a cryptographic key, wherein the cryptographic key is based on the classification result, the hardware protection key in the GW, and the key of the data provider; The data is encrypted using the cryptographic key; The encrypted data is sent to the database for storage. The entry point GW and the controller are operated by the same party, which is different from the party that operates the database.

17. The method according to claim 16, characterized in that, The data received by the ingress GW is encrypted data from the data provider.

18. The method according to claim 17, characterized in that, The method further includes: The encrypted data from the data provider is decrypted using the key provided by the data provider to obtain decrypted data, wherein the data encrypted by the entry GW is the decrypted data.

19. The method according to any one of claims 16 to 18, characterized in that, The encrypted data is sent to the database for storage through the data distribution center.

20. The method according to any one of claims 16 to 18, characterized in that, The response is an authentication from the data provider.

21. The method according to any one of claims 16 to 18, characterized in that, The data upload request also includes one or more of the following: The client identifier of the data provider, Information used for authentication and Security level preferences for the Privacy Database Access Control (PDAC) service.

22. The method according to claim 21, characterized in that, The response includes one or more of the following: The client identifier of the data provider. The controller's authentication identifier and The configuration information of the PDAC service, wherein the configuration information indicates the preference for security protection levels.

23. A method executed by an egress gateway (GW), characterized in that, The method includes: Receive data access requests from the data requester; The data access request is sent to the controller for authentication and authorization. Receive data instructions from the controller; The received data is instructed to be classified to obtain a second classification result; Receive data from the database associated with the data access request; A decryption key is generated based on the second classification result, the hardware protection key of the export GW, and the key of the data provider; The data is decrypted using the decryption key, and the decrypted data is provided to the data requester. The export GW and the controller are operated by the same party, which is different from the party that operates the database.

24. The method according to claim 23, characterized in that, The method further includes: The data is decrypted using the decryption key and the key provided by the data provider.

25. The method according to claim 23 or 24, characterized in that, The data access request includes one or more of the following: The identifier of the data requester. The identifier of the data provider, Data characteristics or data description The data usage description and Instructions that specify whether the data requester should prioritize using an online or offline data access process.

26. The method according to claim 23 or 24, characterized in that, The method further includes: The controller receives an indication message, wherein the indication message includes an identifier of the data requester and the public key of the identifier, a session key and token (SK) encrypted using the public key of the egress GW. tk The data features or descriptions, the identifier of the data provider, and one or more of the security level preferences for the privacy database access control (PDAC) service.

27. The method according to claim 23 or 24, characterized in that, The method further includes: Send a database address request to the log server, wherein the database address request includes one or more of the data provider's identifier and data classification values; Receive a data address response from the log server, wherein the data address response includes one or more of the following: the identifier of the data provider, the address of the database, the location of the database, and the address of the data stored in the database.

28. The method according to claim 23 or 24, characterized in that, The method further includes: Send a client key request to the data provider; Receive a client key transmission message from the data provider, wherein the client key transmission message is a response to the client key request, and the client key transmission message includes the data provider's identifier and the data provider's key, session key, and token SK. tk One or more of the generated encryption keys.

29. An apparatus, characterized in that, The device includes: processor; At least one network interface; A non-transitory machine-readable memory storing machine-readable instructions, wherein, when the machine-readable instructions are executed by the processor, the apparatus is used to perform the method according to any one of claims 16 to 22.

30. An apparatus, characterized in that, The device includes: processor; At least one network interface; A non-transitory machine-readable memory that stores machine-readable instructions, wherein, when the machine-readable instructions are executed by the processor, the means is used to perform the method according to any one of claims 23 to 28.

31. A system, characterized in that, The system includes the apparatus according to claim 29 and the apparatus according to claim 30.

32. A machine-readable memory for storing machine-readable instructions, characterized in that, When the machine-readable instructions are executed by at least one processor, the apparatus is used to perform the method according to any one of claims 16 to 28.

Images