DATABASE ACCESS CONTROL SERVICE IN NETWORKS

Abstract

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

Claims

1. A system for providing a networked database service, the system comprising: a controller configured to: receive one or more data request; and authenticate the one or more data request; and a gateway (GW) in communication with the controller, the GW configured to: receive a response corresponding to at least one of the one or more data request from the controller; receive data from a data provider; and perform data classification on the data according to the response to obtain a classification result; and generate a cryptographic key for accessing a database, the cryptographic key based on the classification result, a hardware-protected key in the GW, and a key from the data provider; wherein the controller and the database are operated by different parties.

2. The system of claim 1, wherein the GW is an ingress GW, the one or more data request includes a data upload request, and the ingress GW is further configured to send the data upload request to the controller, encrypt the data based on the cryptographic key, and send the encrypted data to the database for storage.

3. The system of claim 2, wherein the one or more request includes a data access request from a data requester, and the controller is further configured to perform authentication and authorization on the data access request, and send a data indication to an egress GW, wherein the system further comprises the 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, a hardware-protected key of the egress GW, and the key from the data provider; and decrypt the data based on the decryption key, and provide the decrypted data to the data requester.

4. The system of claim 2 wherein the data received by the ingress GW is encrypted data from the data provider.

5. The system of claim 4 wherein the ingress GW is further configured to decrypt the encrypted data from the data provider based on the key from the data provider to obtain decrypted data, wherein the data encrypted by the ingress GW is the decrypted data.

6. The system of claim 3 wherein the egress GW is configured to decrypt the data by perform a decryption of the data based on the decryption key and the key from the data provider.

7. The system of claim 2 wherein the system further comprises a data distribution center configured to: receive the encrypted data from the ingress GW, and select the database to store the encrypted data, and store an address of the database into a log server, and the ingress GW is configured to send the encrypted data to the database for storage by sending the encrypted data via the data distribution center to the database for storage.

8. The system of claim 1 wherein the controller is further configured to authenticate the data provider via an authentication center.

9. The system of claim 3 wherein the controller is configured to perform the authorization on the data access request by confirming with the data provider that the data access request is authorized.

10. An ingress gateway (GW) apparatus comprising: a processor; at least one network interface; non-transitory machine readable memory storing machine readable instructions which when executed by the processor, configures the ingress GW to: receive data upload request from a data provider, the data upload request including data; send the data upload request to a controller; receive a response corresponding to a data request from a controller; perform data classification on the data according to the response to obtain a classification result; generate a cryptographic key, the cryptographic key based on the classification result, a hardware-protected key in the GW, and a key from the data provider; encrypt the data using the cryptographic key; and send the encrypted data to the database for storage; wherein the database and the GW are operated by different parties.

11. The ingress GW apparatus of claim 10 wherein the data received by the ingress GW is encrypted data from the data provider.

12. The ingress GW apparatus of claim 11 wherein the ingress GW is further configured to decrypt the encrypted data from the data provider based on the key from the data provider to obtain decrypted data, wherein the data encrypted by the ingress GW is the decrypted data.

13. The ingress GW apparatus of claim 10 wherein the ingress GW is configured to send the encrypted data to the database for storage by sending the encrypted data via a data distribution center to the database for storage.

14. The ingress GW apparatus of claim 10 wherein the response is an authentication of the data provider.

16. The ingress GW apparatus of claim 10 wherein the ingress GW and the controller are operated by the same party, which differs from the party operating the database.

17. An egress gateway (GW) apparatus comprising: a processor; at least one network interface; non-transitory machine readable memory storing machine readable instructions which when executed by the processor, configures the egress GW 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 indication from the controller; perform data classification on the received data indication to obtain a second classification result; receive data from the database associated with the data access request; and generate a decryption key based on the second classification result, a hardware-protected key of the egress GW, and the key from a data provider; and decrypt the data based on the decryption key, and provide the decrypted data to the data requester; wherein the database and the GW are operated by different parties.

18. The egress GW apparatus of claim 17 wherein the egress GW is configured to decrypt the data by perform a decryption of the data based on the decryption key and the key from the data provider.

19. The egress GW apparatus of claim 17 wherein the egress GW and the controller are operated by the same party, which differs from the party operating the database.

20. The system of claim 3 wherein the ingress GW, the egress GW and the controller are operated by the same party, which differs from the party operating the database.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0025] Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:

[0026] FIG. 1 illustrates the parties or entities involved, and the roles they play in a PDAC system, according to an embodiment of the present disclosure.

[0027] FIG. 2 illustrates a PDACaaS that includes a PDAC service consortium, according to an embodiment of the present disclosure.

[0028] FIG. 3 illustrates a PDAC system with a one-layer architecture, according to an embodiment of the present disclosure.

[0029] FIG. 4 illustrates a hierarchical PDACaaS architecture, according to an embodiment of the present disclosure.

[0030] FIG. 5 illustrates a PDACaaS confederation architecture, according to an embodiment of the present disclosure.

[0031] FIG. 6 illustrates a PDAC system that further includes an authentication center, according to an embodiment of the present disclosure.

[0032] FIG. 7 illustrates a method of registering a data provider with a PDAC service provider, according to an embodiment of the present disclosure.

[0033] FIG. 8 illustrates a method of registering a data requestor with a PDAC service provider, according to an embodiment of the present disclosure.

[0034] FIGS. 9A through 9D illustrate a data upload method for uploading data to databases in a PDAC system, according to an embodiment of the present disclosure.

[0035] FIGS. 10A through 10C, illustrates a data access method for accessing data stored with a database provider, according to an embodiment of the present disclosure.

[0036] FIG. 11 illustrates data classification based on security levels, according to an embodiment of the present disclosure.

[0037] FIG. 12 illustrates data classification based on data characteristics, according to an embodiment of the present disclosure.

[0038] FIG. 13A illustrates how a public/private key pair may be generated for a data provider or a data requester, according to an embodiment of the present disclosure.

[0039] FIG. 13B illustrates key generation by an ingress GW when a one-level encryption method is used, according to an embodiment of the present disclosure.

[0040] FIG. 13C illustrates key generation by an ingress GW when a two-level encryption method is used, according to an embodiment of the present disclosure.

[0041] FIG. 13D illustrates key generation by an egress GW when a two-level encryption method is used, according to an embodiment of the present disclosure.

[0042] FIG. 13E illustrates key generation by an egress GW when a two-level encryption method is used, according to an embodiment of the present disclosure.

[0043] FIG. 14 illustrates a block diagram of a computing system used to implement a PDAC system, according to an embodiment of the present disclosure.

[0044] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

DETAILED DESCRIPTION

[0045] Embodiments of the invention provide methods, apparatus, and systems to provide a DBaaS that protects and enhances the privacy of data providers and includes authentication and access controls for accessing data stored in one or more database or other storage. Embodiments provide “privacy database access control” (PDAC) and enable the offering of PDAC as a service (PDACaaS) to data providers, data requestors, database providers, and the DBaaS service providers. Embodiments may support a number of levels of data privacy or security, with selectable or customizable protection levels. Multiple PDAC service architectures, multiple cryptographic (encryption and decryption) schemes and multiple options of data privacy processes are also supported. Embodiments decouple the responsibilities of data storage by database providers from data access controls to avoid having a single provider of both data storage and access controls. This decoupling provides a more secure system that is transparent to data providers and data requestors to enable a more secure and trusted data storage environment.

[0046] FIG. 1 illustrates the parties or entities involved in a PDAC system 100 and the roles they play, according to an embodiment of the present disclosure. PDAC system 100 is managed and controlled by a separate entity known herein as a PDAC service provider 108. A PDAC service provider 108 provides access control to a database service provider 106 and databases 112. In embodiments, a database service provider 106 may provide access to one or more databases 112. In the case where access to only a single database is provided, the terms database service provider and database provider may be used interchangeably. In order to prevent unauthorized access by the database service provider 106 to data stored in databases 112, the PDAC service provider 108 may be an independent entity from the database service provider 106. Therefore, for increased security, a PDAC service provider 108 should not provide database services and a database service provider 106 should not be a PDAC service provider 108.

[0047] The data provider 102, or provider for short, is a client of the PDAC service. The data provider 102 may be a person who owns data which is proprietary to themselves or which the data provider 102 has the right to provide and share. A data provider 102 may be the owner of one or more computing devices that create or store private data. In embodiments, the computing device may be a mobile device such as a cellular phone. A data provider 102 may also be an organization that owns data with is private to themselves. A data provider 102 uses the PDACaaS to upload and securely store the proprietary data and utilizes the PDAC service to control and manage access and use of their data by others. Examples of a data provider 102 are a government department storing citizenship information or a medical laboratory storing patients' test results or medical history. An individual may use a PDAC service to keep their financial data, or other personal information. In these examples, there may be a need for the data provider 102 to grant access to some or all of their data to a third party. In other cases, there may exist a legal need for an authorized party to access the data. There may also exist a need for a third party to access a portion of anonymized data, for example to compile health statistics. Embodiments provide mechanisms to inform the data provider 102 should access to their data be requested or demanded.

[0048] Data is stored in a number of independent or affiliated privacy databases 112. A database service provider 106 is used in the PDAC system to provide databases 112 to store proprietary data of data providers 102. These data providers 102 should be different from a PDAC service provider 108 to ensure that the data stored within the database 112 cannot be accessed by the database service provider 106. In embodiments, the database provider 106 does not have access to data in unencrypted or decrypted form and is not aware of the contents of the data stored within. The database 112 may use a number of underlying technologies. It may be relatively simple network attached storage, a remote server, or cloud computing storage. It may also be a sophisticated relational database offering a large amount of storage, robust backup facilities, and fast access. Each database 112 may provide database information including parameters to the database service provider 106 or to the PDAC service provider 108 concerning the location, capabilities, and operational parameters of each database 112. This database information may include, but is not limited to, storage capacity of database, supported programming language, the location or address of the database, etc.

[0049] Data is obtained from database service provider 106 by one of more data requestors 104. A data requester 104 is a person or an organization that desires to access the proprietary data of the data provider 102. In embodiments, access to the data will be authorized by the data provider 102 or through legal means. Examples of data requestors 104 are authorized government entities, health care providers (such as a doctor or dentist) of the data provider 102, or parties designated by the data provider 102. The data requester 102 can access data either on-line or off-line. On-line access is where a data requester 104 can only remotely access and process data that is stored in PDAC system 100. Off-line access is when a data requester 104 may download data and process the data locally. Other methods of access may also be used as well as a mix between on-line and off-line access.

[0050] In embodiments, the data provider 102 may be represented by an agent 110. An agent of data provider 102 can perform required data processing on-behalf of data providers 102 if a mutual level of trust has been established between them or a contract exists for the agent 110 to represent the data provider 102. In general, a data provider can include either the data owner or an agent. In some embodiments only the data owner can provide authorization. In other embodiments, the data provider can provide the authorization, with the data provider being either the data owner or the agent.

[0051] As illustrated in FIG. 2 the PDAC service provider 108 may be grouped with the database service provider 106 and its individual databases 112 to form a PDAC service consortium 202 to provide a PDACaaS. In embodiments, a PDAC controller 302 of FIG. 3 may perform authentication and authorization actions with a third-party authentication, authorization, and accounting (AAA) entity such as authentication center 602 of FIG. 6. The authentication center 602 may be part of a cellular wireless network's core network (CN).

[0052] PDAC service architectures may utilize a number of variations including one-layer architectures, two-layer hierarchical architectures, and PDAC service confederation architectures as described below.

[0053] FIG. 3 illustrates a one-layer architecture according to an embodiment. In this embodiment, a PDAC controller 302, ingress gateway (GW) 306, and egress gateway (GW) 310 have been added to the architecture of FIG. 2. The ingress GW 306 and egress GW 310 may be under the control of the PDAC service provider 108 but in other cases the ingress GW and egress GW may be controlled by different entities. In addition, this architecture may provide a data distribution center 308 and log server 304. Data distribution center 308 may be controlled by different providers such as the PDAC service provider 108, database service provider 106, or a third party. The log server 304 may be controlled by the PDAC service provider 108 or the database service provider 106. The log server 304 is in communication with the data distribution center 308 and the egress GW 310.

[0054] The ingress GW 306 connects to data providers 102 (or their agents 110) for receiving upload data provided by the data provider 102. The ingress GW 306 may also serve to hide the identity of the data provider 102 or their agent 110 from the database provider 106, providing anonymity to the data provider 102 and enabling the uploading of data anonymously. The ingress GW 306 may also provide increased network performance between the data provider 102 and the database 112 by using techniques such as proxies and buffering as is known in the art. An ingress GW 306 may be dedicated to a single data provider 102 or group of data providers, or may serve a specific geographic area. An ingress GW 306 also connects to optional data distribution center 308 which in turn connects to one or more databases 112 provided by database service provider 106 for data storage. An ingress GW 306 includes both control function and data process functions.

[0055] The egress GW 310 connects databases 112 to data requester 104 for the forwarding of data to requester 104. The egress GW 310 may also serve to hide the identity of the data requester 106 from the database provider 106. The egress GW 310 may also provide increased network performance between the data provider 102 and the database 112 by using techniques such as proxies and buffering as is known in the art. An egress GW 310 may be dedicated to a single data provider 102 or group of data providers or may serve a specific geographic area. The egress GW 310 also connects to the log server 304 to provide more efficient data access. An egress GW 310 includes both control function and data process functions. Egress GW 310 can be extended to include sufficient computing resource to enable on-line data processing by a data requester 104 where data is not transferred to the data requester 104.

[0056] Control interfaces between elements of the PDAC system are indicated by the dashed line in FIG. 3. The PDAC service provider 108 operates the PDAC controller 302. The PDAC controller 302 may have control interfaces to the data provider 102 or their agent 110, the ingress GW 306, the egress GW 310, and the data requester 104. The log server 304 may have control interfaces to the data distribution center and the egress GW 310. Other control interfaces not illustrated may also exist as required.

[0057] The PDAC service elements may be implemented in a number of ways including as discrete computing systems or as elements of a network slice, which includes the elements as illustrated in FIG. 3 and interconnections among them. Network slicing refers to a technique for creating virtual networks which separate different types of network traffic, and which can be used in reconfigurable network architectures such as networks employing network function virtualization (NFV). A network slice is composed of a collection of logical network functions that supports communication service requirements of particular use cases. Logical network functions may be instantiated on network hardware including servers, routers, etc. A network slice also includes the necessary links between network functions with allocated bandwidth to meet quality of service (QoS) and quality of experience (QoE) requirements.

[0058] In embodiments, portions of the PDACaaS architecture may be implemented as virtual network functions. In some cases where network access is provided through cellular wireless networks, entities such as ingress GW 306 and egress GW 310, that communicate with data provider 102 and data requester 106, may be implemented in a radio access network (RAN) portion of the network. This may be beneficial where the data provider 102 or data requester 106 is a cellular mobile device or user equipment (UE).

[0059] FIG. 4 illustrates a hierarchical PDACaaS architecture according to an embodiment of the present disclosure. The hierarchical PDACaaS architecture may comprise a multi-layered PDAC service consortium, for example the two-layered PDAC service consortium 400 illustrated in FIG. 4, including first layer consortiums 404a and 404b, and the second layer consortium 402. Each first layer consortium 404a and 404b, includes multiple database providers 106a and 106b, each with their own ingress GW 306a 306b, data distribution center 308a 308b, egress GW 310a 310b, and log server 304a 304b respectively. The second layer consortium 402 includes an ingress GW 406 and egress GW 410 provided so that the two-layer PDAC service consortium 400 appears to a data provider 102 or a data requestor 104 as a one-layer architecture 202 as illustrated in FIG. 3. It can be appreciated that the number of databases 112 and the number of database providers 106a and 106b, in each first layer consortium, may be increased to an arbitrary number and the levels of hierarchy of the ingress GW 406, 306a, and 306b, as well as the levels of hierarchy of the egress GW 410, 310a, and 310b may be increased to account for factors related to performance such as load balancing, latency, geographic location, redundancy, etc.

[0060] FIG. 5 illustrates a PDACaaS confederation architecture according to an embodiment of the present disclosure. The PDACaaS confederation architecture 500 may comprise one or more service consortium 504a and 504b as illustrated. Each service consortium may comprise at least one PDACaaS providers, for example 108a and 108b. The PDACaas providers within the architecture 500 may form a confederation which may be referred to as a “PDAC confederation” or a “PDAC service confederation”. The PDAC confederation includes interface 502 that enables communication and cooperation among multiple PDACaaS providers 108a and 108b for more efficiently performing various actions, such as, data requests, approval requests, record sharing, etc. Accordingly, the PDACaaS providers 108a and 108b may communicate and cooperative together to respond to requests, by data providers 102a or 102b, for uploading data requests from data requester 104a 104b for access to uploaded data, etc. In some embodiments, the PDAC confederation may also comprise one or more of the data providers 102a and 102b, their agents 110a or 110b respectively, and data requestors 104a or 104b as members of a PDAC service confederation. It can be appreciated that the number of PDAC service consortiums 504a and 504b may be increased to an arbitrary number to account for factors related to performance such as load balancing, latency, geographic location, redundancy, etc. As well, a PDAC service confederation of large organizations may also be implemented where each of the participating organizations has its own PDAC service provider. It can also be appreciated that the multi-layer architecture 400 may be combined with a confederation architecture 500 to produce more complex PDACaaS architectures as required or desired for specific implementations.

[0061] The different PDACaaS architectures may be used to enable different levels of security. Multi-layer architecture 400 provides a higher level of reliability and performance over the single layer architecture 300 due to redundancy of database service providers 404a and 404b, and ingress and egress GWs. Confederation architecture 500 enables more secure operations since different PDAC service providers 108a and 108b may provide customer security and service to different types of data providers 102a and 102b, and to different types of service requesters 104a and 104b.

[0062] PDAC service providers 108 provide a number of services and perform a number of actions to provide PDACaaS. The PDAC service provider 108 is responsible for deploying PDAC controller 302. Deploying PDAC controller 302 may include instantiating a network slice, a virtual machine, activating or enabling the controller, as well as deploying a required number of PDAC controllers as is appropriate for the selected PDACaaS architecture.

[0063] In turn, the PDAC controller 302 is responsible for registering and authenticating data providers 102 and controlling data uploading by the data provider 102 or their agent 110. The PDAC controller 302 is also responsible for registering and authenticating data requestors 104 and controlling access to the data by a data requester 104.

[0064] The PDAC controller 302 is responsible for deploying or instantiating any ingress GW 306 or egress GW 310 as required by the PDACaaS architecture. Ingress GW 306 are deployed to provide sufficient interfaces to data providers 102 or their agents 110, and to data distribution centers 308. Ingress GW 306 controls data uploads, including data classification and control of keys for encryption of the data.

[0065] As used herein, cryptographic keys may be referred to simply as keys, and include both encryption keys and decryption keys. Encryption keys refer to cryptographic keys used to encrypt data. Decryption keys refer to cryptographic keys used to decrypt data. An encryption key and decryption key may be part of a pair of cryptographic keys such as a public/private key pair or a symmetric keys as is known in the art.

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

[0067] The PDAC controller 302 is responsible for deploying or instantiating any egress GW 310 to control access to data stored in databases 112 including data classification, controlling of encryption and decryption, online and offline access to the data, and interfacing with data requesters 104, and log server 304. The egress GW 310 may also be extended to interface with cloud computing resources used when data requester 104 is only enabled for online access to the data.

[0068] Each of the database service providers 106 may determine or specify whether to deploy, instantiate, and manage any log servers 304 required by their databases 112. Database service providers 106 also provide and manage databases 112 to store data and deploy database controllers to interface with the ingress GW 306, egress GW 310, or any controller of the ingress GW 306 or egress GW 310.

[0069] FIG. 6 illustrates a PDAC system that further includes an authentication center, according to an embodiment of the present disclosure. The PDAC system 600 of FIG. 6 may be similar to the PDAC system 300 of FIG. 3 with the addition of the authentication centre 602. As discussed herein, in some embodiments, the PDAC controller 302 may perform authentication and authorization actions with a third-party AAA entity such as authentication center 602 as further discussed herein.

[0070] In embodiments, a data provider 102 or a data requester 104 must be registered with the PDAC service provider 108 in order to utilize the PDACaaS. FIG. 7 illustrates a method of registering a data provider 102 with a PDAC service provider 108 according to an embodiment of the present disclosure. In step 701, the data provider 102 sends a provider registration request to the PDAC controller 302. Registration request 701 may include one or more parameters, such as a data provider client ID, and contact information, such as a certificate or address, used to authenticate with an authentication center 602 (as illustrated in FIG. 6). In step 702, the PDAC controller 302 may utilizes the contact information to forward the provider registration request to the ID authentication center 602. In some embodiments, the PDAC controller 302 may utilize an ID authentication center 602 that is already known to the PDAC system or determine the ID authentication center 602 by other means. In step 703, if the data provider 102 is successfully authenticated by the ID authentication center 602, the PDAC controller 302 may register the data provider 102 and may assign or generate encryption keys, such as public/private keys, for communications with the data provider 102, with the PDAC controller 102 retaining the private key and client ID. The PDAC controller 302 may also generate authentication parameters such as a PDAC certificate, or an indication that the data provider is now authorized to receive the PDAC services. In step 704, the PDAC controller 302 sends a provider registration response to the data provider 102. The provider registration response may include one or more parameters such as the public key generated for communications between the PDAC controller 302 and the data provider 102, a list of ingress GWs 306 together with public keys and authentication parameters required to communicate with the ingress GWs 306. In some embodiment, encryption keys for use by the data provider 102 may be delivered over a secure channel. In step 705, the data provider 102 receives the provider registration response and stores the public key for encrypting communications with the PDAC controller 302, public keys for communicating with ingress GWs 306, authentication parameters, and its own public/private key pair. The PDAC controller 302 updates its list of registered data providers. In embodiments where an agent 110 acts on behalf of the data provider 102, the agent 110 may perform the actions of the data provider 102 as listed above.

[0071] FIG. 8 illustrates a method of registering a data requestor 104 with a PDAC service provider 108 according to an embodiment of the present disclosure. In step 801, the data requestor 104 sends a requestor registration request to the PDAC controller 302. The registration request may include one or more parameters, such as a data requestor client ID, and contact information, such as a certificate or address, used to contact the authentication center 602. In step 802, the PDAC controller 302 may utilize the contact information to forward the requestor registration request to the ID authentication center 602. In some embodiments, the PDAC controller 302 may utilize an ID authentication center 602 that is already known to the PDAC system or determine the ID authentication center 602 by other means. In step 803, if the data requestor 104 is successfully authenticated by the ID authentication center 602, the PDAC controller 302 may register the data requestor 104 and may assign or generate encryption keys, such as public/private keys, for communications with the data requestor 104, with the PDAC controller 102 retaining the private key and client ID. The PDAC controller 302 may also generate authentication parameters such as a PDAC certificate, or an indication that the data requestor is now authorized to receive the PDAC services. In step 804, the PDAC controller 302 sends a requestor registration response to the data requestor 104. The requestor registration response may include one or more parameters such as the public key generated for communications between the PDAC controller 302 and the data requestor 104, a list of egress GWs 310 together with public keys and authentication parameters required to communicate with the egress GWs 310. In some embodiment, encryption keys for use by the data requestor 104 may be delivered over a secure channel. In step 805, the data requestor 104 receives the requester registration response and stores the public key for encrypting communications with the PDAC controller 302, public keys for communicating with egress GWs 310, authentication parameters, and its own public/private key pair. The PDAC controller 302 updates its list of registered data requesters.

[0072] FIG. 9, including FIGS. 9A through 9D, illustrates a data upload method 900 for uploading data to databases 112 according to an embodiment. The data upload method 900 may provide for one-layer encryption of data by the data provider 102 and ingress GW 306 as well as two-layer encryption of data by the data provider 102 and ingress GW 306. Prior to the execution of the data upload method 900, the data provider 102 has registered with the PDAC service and obtained encryption keys for itself and a list of ingress GWs 306 together with public keys for the ingress GWs 306. The ingress GWs 306 have been pre-configured with required encryption keys as well. These encryption keys may be hardware-protected and may not be changed. In step 901, data provider 102 sends an upload request to ingress GW 306. The data upload request may include parameters, such as a client ID of the data provider 102, authentication material, PDAC service preferences to allow the PDAC system to classify the data and assign a level of security protection to be used with the uploaded data. In step 802, the ingress GW 306 sends the received upload request to the PDAC controller 302 together with the parameters received in the received upload request. 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 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, or configuration information of the PDAC service, such as a list of security protection levels supported by the PDAC system. In step 905, ingress GW 306 performs authentication using the authentication material in 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 services for the data provider 102.

[0073] FIG. 9B illustrates a first option that utilizes one-level encryption according to an embodiment of the present disclosure. In step 906, a session key and token (SK.sub.tk) is negotiated between the data provider 102 and ingress GW 306 using existing methods such as a Diffie-Hellman (D-H) key exchange. The token generated in step 906 is only valid for the duration of the session for which it is generated. In step 908, the data provider 102 sends a client key delivery message to the ingress GW 306. The client key delivery message may include the data provider's 102 key (K.sub.client) which is encrypted using the session keys generated in step 906. The client key delivery message may also include the data to be uploaded to the ingress GW 306 that may be encrypted using SK.sub.tk or K.sub.client. In step 910, the ingress GW 306 processes the uploaded data from data provider 102 by classifying the data, computing an encryption key (which can be referred to as a cryptographic key), K.sub.ingress, and encrypting the uploaded data using K.sub.ingress. Finally, the ingress GW 306 may destroy K.sub.client to prevent data that has been encrypted using K.sub.client from being accessed.

[0074] FIG. 9C illustrates a second option that utilizes two-level encryption instead of the one-level encryption of steps 906, 908, and 910 as shown in FIG. 9B, according to an embodiment of the present disclosure. Using the second option, in step 912, after step 910, the ingress GW 306 sends a response to the data provider 102. The response may act as an acknowledgement and contain the results of the authentication. This response may indicate the results of the authentication of step 905 in FIG. 9A. In step 914, the data provider 102 sends upload data together with its data characteristic, classification, or a description to ingress GW 306. The upload data is encrypted using the client's key, K.sub.client. In step 916, the ingress GW 306 classifies the uploaded data, computes encryption key, K.sub.ingress, and re-encrypts the data using K.sub.ingress. Therefore, the uploaded data has been encrypted twice; first by the data provider 102 using K.sub.client, then by the ingress GW 306 using K.sub.ingress.

[0075] FIG. 9D illustrates the steps that are performed after encryption by the ingress GW 306. In step 918, the ingress GW 306 sends the data encrypted using option 1 (FIG. 9B) or option 2 (FIG. 9C), together with data classification information to data distribution center 308. In step 920, the data distribution center 308 delivers the encrypted data to the privacy database 112. In step 922, the data distribution center 308 sends a status update message to log server 924. The status update message may include one or more parameters, such as the data provider 102 client ID, the database address, and data classification information. Finally, in step 924, the log server 304 stores the update status message therein.

[0076] FIG. 10, including FIGS. 10A through 10C, illustrates a data access method 1000 for accessing data stored with the database provider 106 according to an embodiment. The data access method 1000 provides options for both on-line data access and off-line data access. Starting with FIG. 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 a data requester 104 ID, a known data provider 102 ID, data characteristics or data descriptions, a description of the use of any accessed data, and whether the data requester 104 would like to use an online or offline data access process. In step 1002, the PDAC controller 302 verifies the data requester 104 and determines the egress GW 310 that may be accessed by the data requester 104. In step 1003, the PDAC controller 302 sends a data access approval request to the data provider 102, or their agent 110, that uploaded or owns the data referred to in the data access request received in step 1001. The data access approval request may include one or more parameters, such as a client ID of data provider 102, ID of data requester 104, use of any accessed data, data characteristics or data descriptions, egress GW's IDs or addresses of egress GWs 310 to be used, etc. The data access approval request may also include the public keys of the egress GWs 310. Should the data provider 102 approve the data access approval request, in step 1004, the data provider 102 generates a session key and token, SK.sub.tk. In step 1005, the data provider 102 sends a data access approval response to the PDAC controller 302. The data access approval response may include one or more parameters such as, SK.sub.tk encrypted using the egress GW's 310 public key. SK.sub.tk may also be used to encrypt K.sub.client. 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 an ID of the data provider 102, and an ID or address of the egress GW 310 with its public key. In step 1007, the PDAC controller 310 then sends a data access indication message to the egress GW 310. The data access indication message may include one or more parameters such as an ID of the data requester 104 with its public key, the SK.sub.tk encrypted using the egress GWs 310 public key, data characteristics or data descriptions, an ID of the data provider 102, and any data processing preferences.

[0077] FIG. 10B is the continuation of the data access method 1000, according to an embodiment of the present disclosure. In step 1008, the egress GW 310 assigns data classifications to the requested data using data characteristics derived from the uploaded 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 an ID of the data provider 102 or a data classification value. In step 1010, the log server 304 responds to 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 an ID of the data provider 102, or an address, location of the database, or an address of the data stored in the database. In step 1011, the egress GW 310 fetches the data from the database or databases where they are stored. In step 1012, the egress GW 310 sends a client key request to the data provider 102. The client key request may include one or more parameters such as the data provider's 102 encryption key (which can also be referred to as the second key), K.sub.client, encrypted using the session key, SK.sub.tk. In step 1013, the data provider 102 responds to the client key request with a client key delivery message sent by the data provider 102 to the egress GW 310.

[0078] FIG. 10C is the continuation of the data access method 1000, according to an embodiment of the present disclosure. In step 1014, the egress GW 310 processes the requested data by computing encryption keys (which may be referred to as cryptographic keys), K.sub.egress, used to decrypt the requested data, destroys K.sub.client which is based on SK.sub.tk with token, and then generates a new session key with token, SK.sub.tk_re, to encrypt the requested data using SK.sub.tk_re. In step 1015, the egress GW 310 sends SK.sub.tk_re, encrypted using the data requestor's 104 public key to the data requestor 104.

[0079] In the case where the requested data is to be processed online, without transferring the data to the data requestor 104, in step 1016, the egress GW 310 may process the data online according to the data requester's 104 data process preferences. Once the egress GW 310 processes the data online, a report or summary may be sent to the data requestor 104. In the case where the requested data is to be processed offline by transferring the data to the data requestor 104, in step 1017, the egress GW 310 may send the requested data, encrypted using SK.sub.tk_re, to the data requestor 104. In some embodiments a combination of online and offline processing may be used, in which case both steps 1016 and 1017 may be used. Finally, in step 1018, the data requestor 104 may destroy data in accordance with SK.sub.tk_re with token. Data may be destroyed when the token of SK.sub.tk_re expires and SK.sub.tk_re becomes invalid at which point the data may no longer be decrypted.

[0080] Embodiments allow for the PDACaaS to be customized to support a number of different applications and clients. Embodiments include multiple PDAC service architectures, multiple methods of data encryption and decryption, and multiple options for requested data to be processed by data requesters 104.

[0081] Customization of PDAC services allows for embodiments of PDACaaS to meet the needs of a large number of clients such as data providers 102 and data requestors 104. Clients may select or define service parameters to customize the PDACaaS for their particular service requirements and the types or characteristics of the data utilized. Some example of data types or characteristics are identification (ID) documents or ID related data, personal health related data or documents, investment data of individuals or businesses, social relation documents such as contact information data, financial or accounting information of individuals or businesses.

[0082] Each provisioned PDAC service can serve multiple data providers 102 or data requesters 104. Each data provider 102 can customize a preferred data protection level to be received from the PDAC service. A set of data protection levels may be specified for particular types of data. A set of data protection levels may include parameters such as architecture, encryption scheme, or privacy. Architectures may include a hierarchical PDACaaS architecture 400, a PDACaaS confederation architecture 500, or a hybrid of different architectures. Encryption (or cryptographic) key parameters may define the keys used for encryption and decryption of data, or whether to use a one-layer or two-layer encryption scheme. Privacy parameters may select between online of offline access for some or all of the data accessed.

[0083] As an example, for highly sensitive data such as identification documents managed by a government entity, a set of data protection levels could include a two-level, hierarchical PDACaaS architecture, a two-layer encryption scheme, and be limited to online access. For less sensitive data such as personal investment records, a set of data protection levels could include a single layer architecture 300 and allow for offline access by a data requestor 104.

[0084] A data provider 102 can select its preferred PDAC service based on the capabilities of available PDAC services. Data providers 102 can request specific features and parameters as part of the data upload method 900, and, in particular as part of the upload request received in step 901. The PDAC controller 302 can also determine the parameters for a data provider 102 based on protection level requirements, types of data, etc. sent be a client in the upload request in step 901.

[0085] In the field of data management, data classification as a part of an information lifecycle management process can be used as a tool to enable or help a PDAC service provider or database provider to determine what baseline security controls are appropriate for safeguarding that data. Each data provider 102 or data requestor 104 may have their own classification and there may also be defined classifications based on the type of industry or organization, such as commercial or government. Data classifications may include security level and data characteristics or type.

[0086] FIG. 11 illustrates data classification in security level, according to an embodiment of the present disclosure. As illustrated in FIG. 11, security levels for the classification of commercial data 1102 may include sensitive, confidential, private, proprietary, and public. Security levels for government data 1104 may include top secret, secret, confidential, sensitive, and unclassified.

[0087] FIG. 12 illustrates data classification in data characteristics, according to an embodiment of the present disclosure. As illustrated in FIG. 12, types of data used for commercial data 1102 may include business data, personal data, social data, health data, environment data, etc. Types of data used for government data 1104 may include personal identification data, military data, police or law data, community data, etc. Other classifications, security levels, etc. may be added or defined as required. In embodiments, the PDAC service may support an arbitrary number of criteria for classifying data and may pre-configure the criteria in ingress GWs 306 or egress GWs 310.

[0088] Embodiments provide for life cycle management for encryption keys that are used in the PDAC system. In particular, public/private key pairs, database encryption keys, and temporary session keys with tokens to limit their use may be supported and managed by the PDAC system.

[0089] After registering with the PDAC system a data provider 102 or a data requester 104 requester may have their own public/private key pair or the PDAC system's public key. The ingress GW 306 or egress GW 310 may also have their own public/private key pairs or the PDAC system's public key. Similarly, the PDAC system may store the public keys of system entities (e.g. data provider 102, data requestor 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, a system entity may store private keys protected by secure hardware. Public/private key pairs may also be set to expire after a pre-determined amount of time or based on a criteria or event such as a hacking attempt being detected.

[0090] FIG. 13A illustrates how a public/private cryptographic key pair may be generated for a data provider 102 or a data requester 104 in an embodiment. At 1302, an initial parameter, such as a password or master key, may be supplied by a client or their agent and input to a key derivation function (KDF). At 1304, the results are client keys, K.sub.client, that may be used to encrypt data and messages. The initial parameter is known only to the client and storage of private keys may be limited to the client's own hardware. K.sub.client may later be revoked to prevent access to data with the use of a token. Self-destructing data may also be implemented using techniques such as Self Destructing Data System (SeDaS), a Vanish system, or similar technology. Data self-destruction may be controlled by a token value that may be assigned by the data provider 102, their agent 110, or the PDAC system. Once the token value expires, K.sub.client is destroyed and data may not be easily decrypted. This feature enabled the data provider 102 to regain control over, or revoke, access to their data.

[0091] Embodiments include database encryption keys to prevent database provider 106 from accessing unencrypted data stored in the PDAC system. For increased security, especially when the database service provider 106 may be a cloud computing provider, database encryption keys may be time limited to a time based on the amount of time the data is expected to be stored in the database 112 and the amount of time that the data may be accessed by a data requestor 104. For example, a cryptographic key time limit may be set to 2 years when the database may be accessed for 2 years by authorized data requestors 104 or other entities. The longer the time encryption keys are valid for, or if they do not expire, the more secure the keys should be.

[0092] In embodiments, data encryption keys may be generated by the ingress GW 306 as illustrated in FIG. 13B. The ingress GW 306 may use a KDF that takes as inputs: K.sub.0, where K.sub.0 is a hardware-protected key specific to the ingress GW 306 and may be kept in a hardware security module (HSM) of the ingress GW 306; K.sub.client, a second key from the data provider 102; and a value derived from a classification of data received from the data provider 102, where the value is determined by the ingress GW 306.

[0093] FIG. 13B also illustrates a one-level encryption method for sending data received from the data provider 102 to the database 112, according to an embodiment of the present disclosure. To start, data encrypted by the data provider 102 with K.sub.client of the data provider 102 is received by the ingress GW 306. At 1310, the ingress GW 306 uses K.sub.client to decrypt the received data. At 1312 the ingress GW 306 determines the classification of the decrypted data. At 1314, in the KDF of the ingress GW 306, the data classification is combined with K.sub.client and K.sub.0, specific to the ingress GW 306 itself, to produce cryptographic (encryption) key pair, K.sub.ingress. At 1316, the ingress GW 306 utilizes K.sub.ingress to encrypt the data for transmission. Finally, at 1318, K.sub.client is destroyed to prevent any further use of K.sub.client.

[0094] FIG. 13C illustrates a two-level encryption method for sending data received from the data provider 102 to the database 112, according to an embodiment of the present disclosure. At 1320, a data classification is obtained by the ingress GW 306. At 1322, in the KDF of the ingress GW 306, the data classification is combined with K.sub.client and K.sub.0, specific to the ingress GW 306 itself, to produce cryptographic (encryption) key pair, K.sub.ingress. At 1324, the ingress GW 306 utilizes K.sub.ingress to encrypt the data for transmission.

[0095] FIG. 13D illustrates a two-level decryption method for sending data received from the database 112 and sending it to a data requester 104, according to an embodiment of the present disclosure. At 1330, a data classification is obtained by the egress GW 310. At 1332 in the KDF of the egress GW 310, the data classification is combined with K.sub.0, where K.sub.0 is a hardware-protected key specific to the egress GW 310 itself and a second key K.sub.client, to produce cryptographic (decryption) key pair, K.sub.egress. At, 1334, the egress GW 310 utilizes K.sub.egress to decrypt the data once. Then, at 1336, the egress GW 310 utilizes K.sub.client to decrypt the data once more for transmission to the data requester 104. Finally, at 1338, K.sub.client is destroyed to prevent any further use of K.sub.client.

[0096] FIG. 13E illustrates a one-level decryption method for sending data received from the database 112 and sending it to a data requester 104, according to an embodiment of the present disclosure. At 1340, a data classification is obtained by the egress GW 310. At 1342, in the KDF of the egress GW 310, the data classification is combined with K.sub.0, specific to the egress GW 310 itself and second key K.sub.client, to produce cryptographic (decryption) key pair, K.sub.egress. At 1344, the egress GW 310 utilizes K.sub.egress, received from the ingress GW 306 to decrypt the data for transmission to the data requester 104. Finally, at 1346, K.sub.client is destroyed to prevent any further use of K.sub.client.

[0097] Temporary session keys may be negotiated between the egress GW 306 and the data requester 104, or between a data provider 102 and the ingress GW 306, to encrypt data. This session key may be encrypted using public keys.

[0098] FIG. 14 is a block diagram of a computing system 1400 that may be used for implementing the devices and methods disclosed herein. Specific devices may utilize all of the components shown or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, 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 a memory 1415, and may optionally also include a mass storage device 1420, a video adapter 1425, and an I/O interface 1430 (shown in dashed lines).

[0099] The CPU 1405 may comprise any type of electronic data processor. The memory 1415 may comprise 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 a combination thereof. In an embodiment, the memory 1415 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs. The bus 1410 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, or a video bus.

[0100] The mass storage 1420 may comprise any type of non-transitory storage device configured to store data, programs, and other information and to make the data, programs, and other information accessible via the bus 1410. The mass storage 1420 may comprise, for example, one or more of a solid state drive, hard disk drive, a magnetic disk drive, or an optical disk drive.

[0101] The video adapter 1425 and the I/O interface 1440 provide optional interfaces to couple external input and output devices to the processing unit 1402. Examples of input and output devices include a display 1435 coupled to the video adapter 1425 and an I/O device 1440 such as a touch-screen coupled to the I/O interface 1430. Other devices may be coupled to the processing unit 1402, and additional or fewer interfaces may be utilized. For example, a serial interface such as Universal Serial Bus (USB) (not shown) may be used to provide an interface for an external device.

[0102] The processing unit 1402 may also include one or more network interfaces 1450, which may comprise wired links, such as an Ethernet cable, and/or wireless links to access one or more networks 1445. The network interfaces 1450 allow the processing unit 1402 to communicate with remote entities via the networks 1445. For example, the network interfaces 1450 may provide wireless communication via one or more transmitters/transmit antennas and one or more receivers/receive antennas. In an embodiment, the processing unit 1402 is coupled to a local-area network or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, or remote storage facilities.

[0103] Through the descriptions of the preceding embodiments, the present invention may be implemented by using hardware only or by using software and a necessary universal hardware platform. Based on such understandings, the technical solution of the present invention may be embodied in the form of a software product. The software product may be stored in a non-volatile or non-transitory storage medium, which can be a compact disk read-only memory (CD-ROM), USB flash disk, or a removable hard disk. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to execute the methods provided in the embodiments of the present invention. For example, such an execution may correspond to a simulation of the logical operations as described herein. The software product may additionally or alternatively include number of instructions that enable a computer device to execute operations for configuring or programming a digital logic apparatus in accordance with embodiments of the present invention.

[0104] Although the present invention has been described with reference to specific features and embodiments thereof, it is evident that various modifications and combinations can be made thereto without departing from the invention. The specification and drawings are, accordingly, to be regarded simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the present invention.