HK1243524B - Multi-party encryption cube processing apparatuses, methods and systems - Google Patents

Description

Multi-party encrypted cube processing device, method and system

This application for letter patent disclosure describes inventive aspects that are directed to various new innovations (hereinafter referred to as the "disclosure") and contains material that is protected by copyright, screen work, and/or other intellectual property rights. The respective owners of such intellectual property have no objection to the facsimile reproduction by anyone of the disclosure, as it appears in the published Patent Office file/records, but otherwise reserve all rights.

priority

This application claims priority to U.S. Patent Application Serial No. 62/115,178, filed on February 12, 2015, and entitled “Cloud Encryption Key Broker Apparatus, Methods, and Systems,” the entire contents of which are expressly incorporated herein by reference.

Technical Field

The present innovation relates generally to multi-party encryption methods and, more particularly, to multi-party encryption cube processing devices, methods and systems or MPEC.

Background Art

Secure multi-party computation methods contribute to methods that allow multiple parties to jointly process their data while keeping their respective data private from one another. In other words, these methods allow multiple parties to jointly compute a value based on multiple pieces of individually held secret information without revealing their respective confidential information to one another in the process.

This is useful, for example, when users such as companies and vendors need to communicate and exchange ideas but need to keep their underlying data protected. For example, a merchant data owner may be interested in pooling data to perform transaction data analysis. In this instance, the merchant data owner can view a summarized version of the transaction data (or another form of aggregated data) without viewing the underlying data.

While secure multi-party computation methods can help generate such summary data without revealing each party's underlying confidential data to the others, current methods for securing data exchange between multiple parties tend to be slow from a performance perspective.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying appendices and/or figures illustrate various non-limiting, exemplary innovative aspects according to the present description:

The number preceding each reference numeral in the drawings indicates the figure in which that reference numeral is introduced and/or detailed. Thus, a detailed discussion of reference numeral 101 will be found and/or introduced in Figure 1. Reference numeral 201 is introduced in Figure 2, etc.

FIG1 is a block diagram depicting user access to MPEC.

FIG. 2 is a block diagram depicting the use of MPEC to allow two data-owning users to access each other's data.

FIG3 is a flow chart depicting an operational scenario using MPEC.

4-6 are block diagrams depicting various process flows of MPEC.

7-8 depict exemplary computers and software components that may be used with the operations described herein.

Summary of the Invention

Disclosed herein are computer-implemented systems and methods for use, for example, within secure multi-party computation. For example, systems and methods for storing preferences are disclosed. A data set is stored based on the preferences. Determining processing a query involves performing permissible operations on the data set based on the preferences.

As another example, a system and method are disclosed for storing, by one or more data processors, operational preferences and cryptographic preferences associated with a data set. The data set is stored based on the operational preferences and cryptographic preferences. A query associated with at least the data set is analyzed. A determination is made that processing the query involves performing an allowable operation on the data set based on the operational preferences. One or more cryptographic protocols are selected based on a first cryptographic preference. The allowable operation is performed on the data set using the one or more cryptographic protocols.

DETAILED DESCRIPTION

FIG1 shows a block diagram illustrating an exemplary embodiment of MPEC at 100. In FIG1 , one or more databases 102 are provided to store information of multiple data owners. The database 102 may be in the form of a centralized database warehouse for storing transaction data from multiple merchants, payment service providers, etc.

Users 104 who wish to analyze the stored data may access the data stored in database 102 through MPEC 106. MPEC 106 allows analysis results to be "public" (e.g., revealed to the requesting user) while the underlying data in database 102 remains confidential and secure even from other participating data owners.

Users 104 may interact with MPEC 106 directly or indirectly through a number of means, such as via one or more networks 108. Server 110, accessible through network 108, may host system 106. Database 102 may store data to be analyzed by system 106 and any intermediate or final data generated by system 106.

FIG2 illustrates an information exchange mechanism 200 for allowing two data-owning users 202 to access each other's data via the MPEC 106. To achieve this, at least in part, the MPEC 106 provides encryption and data analysis tools, as shown at 204, to the data owners. The system may provide predefined algorithms/protocols from which the owners may select to exchange information. For example, the owners may select from a list of algorithms/protocols, such as Yao's encryption or other encryption techniques known in the art. (The Yao's encryption technique is discussed in U.S. Publication No. US 2014/0351104A1, entitled "Data Management Systems and Processing for Financial Risk Analysis," which is incorporated herein by reference for all purposes.)

Additionally, each data owner can specify how their data will be handled. Data owners can do this by specifying preferences 202 (e.g., configurations) to the MPEC 106. Owner-specific preferences can include a set of data sets specific to each owner with a defined set of allowed operations (e.g., retrieval, join, etc.). For example, another preference can specify that multiple cryptographic algorithms/protocols can be used for each data operation.

The preferences are used in processing query requests. For example, MPEC 106 determines whether the query involves performing a permitted operation on the owner's data based on pre-specified operation preferences. The cryptographic preferences select which cryptographic protocol or protocols will be used to perform the permitted operation on the data set. The query results are sent to the requester, but at a level that maintains the confidentiality of other users' data.

Figure 3 depicts an example of an operational scenario involving MPEC. The operational scenario involves an encrypted database where multiple data owners can ask questions of the database and then receive aggregate statistical responses or summary lists based on the underlying sensitive data contained in the database. In this scenario, the data owners do not have specific knowledge of what is actually contained in the database.

In the example, the user provides preferences at 300 for the MPEC to use in performing its operations. The preferences include allowed operations and preferred encryption protocols. It should be understood that in other operating scenarios, the preferences may include only allowed operations or only preferred encryption protocols, or a combination thereof.

At 302 and 304, sensitive information is received from multiple data owners. In this operational scenario, the sensitive information includes SKU (stock keeping unit) information associated with a merchant. The SKU information may contain identification of different products and services that can be purchased from the merchant's business. In this example, the sensitive information also includes transaction data from a payment processing company.

At 306, one of the data owners provides a query involving sensitive information. At 308, the MPEC performs permitted operations on the data sets provided by the first and second data users using an encrypted protocol according to the specified preferences. An aggregated result is then provided to the first data owner.

For example, a merchant data owner can provide SKU data and another data owner can provide transaction data. MPEC can combine the two data in an encrypted space and provide aggregate type information, such as what is the maximum amount line by item. A cube can be generated that allows information to be encrypted at different levels within the cube using a selected encryption protocol.

FIG4 depicts the software computer components of an exemplary embodiment of the MPEC. Multiple encryption protocols 400 can be used within the MPEC. The MPEC selects which encryption protocols 400 to handle requests/queries 404 based on stored preferences 402. When a cube is first set up for a party, the party selects which set of operations can be performed, thereby limiting what cubes can be generated. This provides greater security for data use. Additionally, data owners can provide their own encryption protocols for use within the MPEC. This is possible if the data owner has come to trust a particular encryption protocol and that protocol is not currently available within the MPEC.

MPEC utilizes specialized encryption algorithms based on preferences for specific tasks. For example, computations across data types can be performed using homomorphic methods or Yao-style algorithms. This allows each party to determine the final protocol and provides greater security by creating a heterogeneous environment within the deployment. More specifically, for each request, the platform understands the configurations of each party and employs the appropriate protocol to extract data.

The MPEC may further include functionality that operates as a routing layer 406. The routing layer 406 redirects the request/query 404 to those software and database components that will be involved in processing the request/query 404.

Figure 5 illustrates a query analyzer 500 analyzing the query to determine the best way to process the query. This may involve a two-tier system 502 for processing the query.

As an example of a two-tier processing system, Figure 6 illustrates the additional optimal processing capabilities provided by using a database router 602 and a database manager 604 that allow smaller types of query processing to use in-memory storage 606 for performance gains, or a file system 608 for other types of processing of larger data sets. In this way, an intelligent layer for diagnostics is provided for the cube.

More specifically, methods that require a large amount of memory per data element can use a distributed file system such as Hadoop. Methods with smaller requirements can use an in-memory database. Based on the volume and type of queries, MPEC can automatically move data in and out of memory to enhance performance. For specific protocols, data can be split and the algorithm adapted to enhance performance on the fly. For example, if optimization is required, the system can select an action based on the set actions of the algorithm involved. If the algorithm allows the functionality to be split into sub-cubes, the system will select this action. If this is not available, more memory can be allocated.

The query analyzer in this example examines data usage, algorithms, and query complexity to determine if re-optimization should be performed. This could, for example, involve re-encrypting the space based on usage history. Alternatively, the entire cube might not need to be encrypted; only the parts that need to be secure when providing results to the requester need to be encrypted.

It will be appreciated that other approaches besides in-memory storage may be used, such as a graph database that uses a semantically queried graph structure with nodes, edges, and properties to represent and store data. In this way, MPEC allows complex data structures, such as graphs, to be expressed using a variety of encryption techniques.

As a further illustration of the broad scope of the systems and methods disclosed herein, one or more of the methods disclosed herein may be used to configure MPEC to provide a framework for a collection of specialized encryption algorithms that enable a wide range of use cases while providing optimal performance.

FIG7 and FIG8 depict exemplary systems for use with the operations disclosed herein. For example, FIG7 depicts an exemplary system 700 comprising a computer architecture in which a processing system 702 (e.g., one or more computer processors located in a given computer or in multiple computers that may be separate and distinct from one another) comprises an MPEC 704 executing on the processing system 702. The processing system 702 has access to a computer-readable memory 707 in addition to one or more data storage devices 708. The one or more data storage devices 708 may contain user preferences 710. The processing system 702 may be a distributed parallel computing environment that can be used to process very large data sets.

8 depicts a system 720 comprising a client-server architecture. One or more user PCs 722 access one or more servers 724 running an MPEC system 737 on a processing system 727 via one or more networks 728. The one or more servers 724 have access to a computer readable memory 730 and one or more data storage devices 732.

In Figures 7 and 8, a computer-readable memory (e.g., at 707) or a data storage device (e.g., at 708) may contain one or more data structures for storing and associating various data used in the exemplary system. For example, a data structure stored in any of the aforementioned locations may be used to store data including user preferences, etc.

Each of the element manager, real-time data buffer, conveyor, file input processor, database index shared access memory loader, reference data buffer, and data manager may comprise a software application stored in one or more of a disk drive connected to the disk controller, ROM, and/or RAM. The processor may access one or more components when needed.

The display interface may permit information from the bus to be displayed on a display in audio, graphical, or alphanumeric format.Various communication ports may optionally be used for communication with external devices.

In addition to these computer-type components, the hardware may also include data input devices such as a keyboard, or other input devices such as a microphone, remote control, pointer, mouse, and/or joystick.

In addition, the methods and systems described herein can be implemented on many different types of processing devices by program code comprising program instructions that can be executed by the device processing subsystem. The software program instructions can include source code, object code, machine code, or any other stored data that is operable to cause the processing system to perform the methods and operations described herein and can be provided in any suitable language (e.g., C, C++, JAVA, or any other suitable programming language). However, other embodiments can also be used, such as firmware or even appropriately designed hardware configured to perform the methods and systems described herein.

The data of the described systems and methods (e.g., associations, mappings, data inputs, data outputs, intermediate data results, final data results, etc.) can be stored and implemented in one or more different types of computer-implemented data storage devices, such as different types of storage devices and programming constructs (e.g., RAM, ROM, flash memory, flat files, databases, programming data structures, programming variables, IF-THEN (or similar type) statement constructs, etc.). It should be noted that a data structure describes a format for organizing and storing data in a database, program, memory, or other computer-readable medium for use by a computer program.

The computer components, software modules, functions, data storage devices and data structures described herein may be connected to each other directly or indirectly to allow the flow of data required for their operation. It should also be noted that a module or processor includes, but is not limited to, code units that perform software operations and may be implemented as, for example, subroutine code units or software function code units or objects (such as in an object-oriented paradigm) or applets or in a computer scripting language, or as another type of computer code. Software components and/or functionality may be located on a single computer or distributed across multiple computers, depending on the circumstances at hand.

Although the present disclosure has been described in detail and with reference to specific embodiments thereof, it will be apparent to those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the embodiments. Therefore, it is intended that the present disclosure encompass modifications and variations of the present disclosure.

Claims (13)

1. A method for use within secure multi-party computation, comprising: One or more data processors store operation preferences and password preferences containing allowed database operations, which are associated with the dataset; The dataset is stored by one or more data processors based on the operational preferences and the cryptographic preferences; The queries associated with at least the dataset are analyzed by the one or more data processors; The one or more data processors determine that processing the query involves performing a permissible operation on the dataset based on the operational preference; One or more cryptographic protocols are selected by the one or more data processors based on a first cryptographic preference; and The permitted operations are performed on the dataset by the one or more data processors using the one or more cryptographic protocols, wherein merchant data owners jointly process their associated data in response to the inquiry to perform transaction data analysis while keeping their respective data private from each other, wherein a summary version of the transaction data analysis is provided to one of the merchant data owners. 2. The method of claim 1, wherein a centralized database repository stores transaction data from multiple merchants and payment service providers. 3. The method of claim 1, wherein the cryptographic preferences are selected from a plurality of predefined cryptographic protocols. 4. The method of claim 1, wherein the operation preference includes permitted combination operations. 5. The method of claim 1, wherein the operation preference includes allowed search operations. 6. The method of claim 1, wherein a two-tier system is used, wherein a distributed file system is used for processing of larger datasets for each data element, and an in-memory storage device is used for processing of smaller datasets compared to larger datasets. 7. A system for use within secure multi-party computation, comprising: Memory; and One or more processors configured to communicate with the memory and configured to issue processing instructions stored in the memory to perform the following operations: One or more data processors store operation preferences and password preferences containing allowed database operations, which are associated with the dataset; The dataset is stored by one or more data processors based on the operational preferences and the cryptographic preferences; The queries associated with at least the dataset are analyzed by the one or more data processors; The one or more data processors determine that processing the query involves performing a permissible operation on the dataset based on the operational preference; One or more cryptographic protocols are selected by the one or more data processors based on a first cryptographic preference; and The permitted operations are performed on the dataset by the one or more data processors using the one or more cryptographic protocols, wherein merchant data owners jointly process their associated data in response to the inquiry to perform transaction data analysis while keeping their respective data private from each other, wherein a summary version of the transaction data analysis is provided to one of the merchant data owners. 8. The system of claim 7, wherein a centralized database repository stores transaction data from multiple merchants and payment service providers. 9. The system of claim 7, wherein the cryptographic preferences are selected from a plurality of predefined cryptographic protocols. 10. The system of claim 7, wherein the operation preference includes permitted combination operations. 11. The system of claim 7, wherein the operation preference includes permitted retrieval operations. 12. The system of claim 7, wherein a two-tier system is used, wherein a distributed file system is used for processing of larger datasets for each data element, and an in-memory storage device is used for processing of smaller datasets compared to larger datasets. 13. A processor-readable non-transitory medium, wherein the storage processor issues instructions to perform the following operations: One or more data processors store operation preferences and password preferences containing allowed database operations, which are associated with the dataset; The dataset is stored by one or more data processors based on the operational preferences and the cryptographic preferences; The queries associated with at least the dataset are analyzed by the one or more data processors; The one or more data processors determine that processing the query involves performing a permissible operation on the dataset based on the operational preference; One or more cryptographic protocols are selected by the one or more data processors based on a first cryptographic preference; and The permitted operations are performed on the dataset by the one or more data processors using the one or more cryptographic protocols, wherein merchant data owners jointly process their associated data in response to the inquiry to perform transaction data analysis while keeping their respective data private from each other, wherein a summary version of the transaction data analysis is provided to one of the merchant data owners.