US20230367888A1

US20230367888A1 - Multi-party encryption cube processing apparatuses, methods and systems

Info

Publication number: US20230367888A1
Application number: US18/357,530
Authority: US
Inventors: Theodore Harris; Scott Edington
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2015-02-12
Filing date: 2023-07-24
Publication date: 2023-11-16
Also published as: ES2904528T3; AU2016219159B2; US20190108352A1; EP3256949A4; US9898612B2; EP3256949A1; US20160239670A1; BR112017014399A2; US20210150039A1; SG11201705566VA; CA2972096A1; US10902134B2; US20190311138A1; CN107430557A; US10366239B2; HK1243524A1; AU2016219159A1; US11709947B2; CN107430557B; US10157284B2

Abstract

Computer-implemented systems and methods are disclosed herein for use within secure multi-party computation. A system and method are used for storing an operation preference and a cryptographic preference. A data set is stored based on the operation preference and the cryptographic preference. A determination is made that processing the query involves performing an allowable operation on the data set based on the operation preference.

Description

PRIORITY

This application claims priority to U.S. Patent Application Ser. No. 62/115,178, filed Feb. 12, 2015 and entitled “Multi-Party Encryption Cube Processing Apparatuses, Methods and Systems.” The entire contents of the aforementioned application is expressly incorporated by reference herein.
This application for letters patent disclosure document describes inventive aspects directed at various novel innovations (hereinafter “disclosure”) and contains material that is subject to copyright, mask work, and/or other intellectual property protection. The respective owners of such intellectual property have no objection to the facsimile reproduction of the disclosure by anyone as it appears in published Patent Office file/records, but otherwise reserve all rights.

FIELD

The present innovations are directed generally to multi-party encryption approaches and more particularly, to MULTI-PARTY ENCRYPTION CUBE PROCESSING APPARATUSES, METHODS AND SYSTEMS or MPEC.

BACKGROUND

Secure multi-party computation approaches help create methods for parties to jointly process their data while keeping their respective data private from one another. Stated differently, these approaches allow multiple parties to jointly compute value(s) based on individually held secret pieces of information without revealing their respective confidential information to one another in the process.
This is useful, for example, when users, such as companies and firms, need to communicate and exchange ideas but need to keep their underlying data secured. For example, merchant data owners may be interested in pooling data together to perform transactional data analysis. The merchant data owners, in this example, can view a summarized version of the transactional data (or another form of aggregated data) and not the underlying data.
While secure multi-party computation approaches help generate such summarized data without surfacing the underlying confidential data of each party to others, today's approaches for securing the data exchange between parties, however, tend to be slow from a performance perspective.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying appendices and/or drawings illustrate various non-limiting, example, innovative aspects in accordance with the present descriptions:

The leading number of each reference number within the drawings indicates the figure in which that reference number is introduced and/or detailed. As such, a detailed discussion of reference number 101 would be found and/or introduced in FIG. 1 . Reference number 201 is introduced in FIG. 2 , etc.

FIG. 1 is a block diagram depicting access by users of an MPEC.

FIG. 2 is a block diagram depicting use of an MPEC for allowing two data owning users to access one another's data.

FIG. 3 is a flowchart depicting an operational scenario using an MPEC.

FIGS. 4-6 are block diagrams depicting various processing flows of an MPEC.

FIGS. 7-8 depict example computer and software components that can be used with the operations described herein.

SUMMARY

Computer-implemented systems and methods are disclosed herein, such as, for use within secure multi-party computations. For example, a system and method are disclosed for storing preferences. A data set is stored based on the preferences. A determination is made that processing the query involves performing an allowable operation 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, an operation preference and a cryptographic preference, which are both associated with a data set. The data set is stored based on the operation preference and the cryptographic preference. 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 operation preference. One or more cryptographic protocols are selected based on the first cryptographic preference. The one or more cryptographic protocols are used to perform the allowable operation on the data set.

DETAILED DESCRIPTION

FIG. 1 shows at 100 a block diagram illustrating example embodiments of the MPEC. In FIG. 1 , one or more databases 102 are provided to store multiple data owners' information. The database(s) 102 can be in the form of a centralized database warehouse for storing transactional data from multiple merchants, payment service providers, etc.
Users 104 wishing to analyze the stored data can access data stored in the database(s) 102 through an MPEC 106. The MPEC 106 allows the analysis results to be “public” (e.g., surfaced to the requesting user), while the underlying data in the database(s) 102 remains confidential and secure even from other participating data owners.
The users 104 can interact directly or indirectly with the MPEC 106 through a number of ways, such as over one or more networks 108. Server(s) no accessible through the network(s) 108 can host the system 106. The database(s) 102 can store the data to be analyzed by the system 106 as well as any intermediate or final data generated by the system 106.
FIG. 2 shows an information exchange mechanism 200 for allowing two data owning users 202 to access one another's data via an MPEC 106. To accomplish this at least in part, the MPEC 106 provides data owners with encryption and data analysis tools as shown at 204. The system can provide predefined algorithms/protocols from which the owners can select to exchange information. For example, owners can select from a list of algorithms/protocols such as the Yao encryption method or other encryption techniques known in the field. (The technology of the Yao encryption method is discussed in U.S. Publication No. US 2014/0351104A1 entitled “Data Management Systems and Processing for Financial Risk Analysis” which is incorporated by reference herein for all purposes.)
Additionally, each data owner may specify how its data is to be handled. A data owner can do this by specifying party preferences 202 (e.g., configurations) to the MPEC 106. Owner-specific preferences can include each owner-specific data set having a defined set of allowed operations (e.g., retrieving, joining, etc.). Another preference, for example, can specify that each data operation can use multiple cryptographic algorithms/protocols.
The preferences are used in processing query requests. For example, the MPEC 106 determines whether the query involves performing an allowable operation on the owners' data based on a pre-specified operation preference. A cryptographic preference selects which one or more cryptographic protocols are to be used in performing the allowable 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.
FIG. 3 depicts an example of an operational scenario involving the MPEC. The operational scenario involves an encrypted database where multiple data owners can ask questions from the database and then derive aggregate statistics responses or a summarized list based upon the underlying sensitive data contained in the database. In this scenario, the data owners do not know specifically what was actually contained within the database.
In the example, users provide at 300 preferences for use by the MPEC in performing its operations. The preferences include allowable operations and preferred encryption protocols. It should be understood that in other operational scenarios preferences may include only allowable operations or only preferred encryption protocols or combinations 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 the merchant. SKU information can contain identification for distinct products and services that can be purchased in a merchant's business. The sensitive information also includes in this example a payment processing company's transactional data.
At 306, one of the data owners provides a query involving the sensitive information. At 308, the MPEC performs the allowable operation on the data sets provided by the first and second data users with encryption protocols in accordance with the specified preferences. The aggregated results are then provided to the first data owner.
For example, a merchant data owner can provide SKU data and another data owner can provide the transactional data. The MPEC can join the two pieces of data in an encrypted space and provide aggregated type information, such as what was the maximum amount line item-wise. A cube can be created that allows the information to be encrypted using the selected encryption protocols at different levels within the cube.
FIG. 4 depicts software computer components in an example embodiment of the MPEC. Multiple encryption protocols 400 are available for utilization within the MPEC. The MPEC selects those encryption protocols 400 to handle a request/query 404 based upon the stored preferences 402. When the cubes are first set up for a party, the party selects what set of operations can be performed, thereby restricting what cubes can be generated. This results in providing greater security for data usage. Further, data owners can provide their own encryption protocols for use within the MPEC. This can occur if the data owner has come to trust a particular encryption protocol and that protocol is currently not present within the MPEC.
With the preferences, the MPEC employs dedicated encryption algorithms for a specific task. For example, computations across join-type data may be performed by a Homomorphic-like method or Yao's algorithm. This allows parties to decide on the final protocol and provides greater security by creating a heterogeneous environment in deployment. More specifically, for a request the platform knows the configuration of each party and employs the proper protocol to extract the data.
The MPEC can further include functionality to operate as a routing tier 406. The routing tier 406 redirects the request/query 404 to those software and database components that should be involved in processing the request/query 404.
FIG. 5 illustrates that a query analyzer 500 analyzes the query to determine the optimal way for processing the query. This can involve a two tier system 502 for processing the query.
As an example of a two tier processing system, FIG. 6 illustrates additional optimal processing capability by using a database router 602 and database manager 604 that allows smaller type query processing to use in-memory storage 606 for performance gains or a file system 608 for other type processing of larger data sets. In this way, an intelligence layer for diagnostics is provided for the cube.
More specifically, methods which require large in-memory usage for each data element can use distributed files system like Hadoop. Methods with smaller requirements can use in-memory databases. Based on volumes and types of queries, the MPEC can move data in and out of memory automatically to enhance performance. For certain protocols, data may be split and algorithms adapted to enhance performance on the fly. For example, if optimization is required the system can choose an action based on set actions for the involved algorithm. If the algorithm allows splitting functionality into sub cubes, the system will choose this action. If this is not available then more memory may be allocated.
The query analyzer in this example examines, the data usages, algorithm and query complexity to determine if a re-optimization should be performed. For example, this can include re-encrypting the space based upon usage history. Additionally, the entire cube may not need to be encrypted, only those parts which need to be secure in providing the results to the requestor.
It should be understood that other approaches can be used in addition to in-memory storage, such as a graph database which uses graph structures for semantic queries with nodes, edges, and properties to represent and store data. In this way, the MPEC allows complex data structures, like a graph to be expressed using multiple encryption techniques.
As a further illustration of the wide scope of the systems and methods disclosed herein, an MPEC can be configured with one or more of the approaches disclosed herein to provide a framework for a collection of dedicated encryption algorithms enabling a broad spectrum of use cases while providing optimal performance.
FIGS. 7 and 8 depict example systems for use with the operations disclosed herein. For example, FIG. 7 depicts an exemplary system 700 that includes a computer architecture where 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) includes an MPEC 704 being executed on the processing system 702. The processing system 702 has access to a computer-readable memory 707 in addition to one or more data stores 708. The one or more data stores 708 may include user preferences 710. The processing system 702 may be a distributed parallel computing environment, which may be used to handle very large-scale data sets.
FIG. 8 depicts a system 720 that includes 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 may access a computer-readable memory 730 as well as one or more data stores 732.
In FIGS. 7 and 8 , computer readable memories (e.g., at 707) or data stores (e.g., at 708) may include one or more data structures for storing and associating various data used in the example systems. 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 managers, real-time data buffer, conveyors, file input processor, database index shared access memory loader, reference data buffer and data managers may include a software application stored in one or more of the disk drives connected to the disk controller, the ROM and/or the RAM. The processor may access one or more components as required.
A display interface may permit information from the bus to be displayed on a display in audio, graphic, or alphanumeric format. Communication with external devices may optionally occur using various communication ports.
In addition to these computer-type components, the hardware may also include data input devices, such as a keyboard, or other input device, such as a microphone, remote control, pointer, mouse and/or joystick.
Additionally, the methods and systems described herein may be implemented on many different types of processing devices by program code comprising program instructions that are executable by the device processing subsystem. The software program instructions may include source code, object code, machine code, or any other stored data that is operable to cause a processing system to perform the methods and operations described herein and may be provided in any suitable language such as C, C++, JAVA, for example, or any other suitable programming language. Other implementations may also be used, however, such as firmware or even appropriately designed hardware configured to carry out the methods and systems described herein.
The systems' and methods' data (e.g., associations, mappings, data input, data output, intermediate data results, final data results, etc.) may be stored and implemented in one or more different types of computer-implemented data stores, 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 is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.
The computer components, software modules, functions, data stores and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. It is also noted that a module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The software components and/or functionality may be located on a single computer or distributed across multiple computers depending upon the situation at hand.
While the disclosure has been described in detail and with reference to specific embodiments thereof, it will be apparent to one skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the embodiments. Thus, it is intended that the present disclosure cover the modifications and variations of this disclosure.

Claims

1.-21. (canceled)

22. A client system for use in database operations on data associated with multiple parties, the client system comprising:

a memory; and

one or more processors for executing instructions stored in the memory to:

transmit, to a data processing system, first data handling preferences associated with first transaction data stored in a database;

transmit, to the data processing system, a query associated with an attribute of the first transaction data; and

receive, from the data processing system, a summarized version of a transaction data analysis, wherein the transaction data analysis is based on:

the attribute of the first transaction data;

second transaction data stored in the database, the second transaction data inaccessible to the client system; and

an allowable operation determined by the data processing system according to the first data handling preferences and second data handling preferences associated with the second transaction data, wherein the allowable operation is performed on the first transaction data and the second transaction data; and

wherein the summarized version of the transaction data analysis excludes the second transaction data.

23. The client system of claim 22, wherein the first data handling preferences comprise at least one of a first operation preference or a first encryption protocol.

24. The client system of claim 23 wherein the allowable operation is performed with the first encryption protocol.

25. The client system of claim 23, wherein the second data handling preferences comprise at least one of a second operation preference or a second encryption protocol.

26. The client system of claim 25, wherein the allowable operation is performed with the encryption protocol and the second encryption protocol.

27. The client system of claim 23 wherein the first operation preference includes at least one of an allowed join operation or an allowed retrieval operation.

28. The client system of claim 22, wherein the summarized version of the transaction data analysis comprises aggregated statistics.

29. The client system of claim 22, wherein the summarized version of the transaction data analysis excludes the first transaction data.

30. The client system of claim 23, wherein the first data handling preferences comprises Yao's algorithm.

31. The client system of claim 27 wherein the allowable operation comprises the allowed join operation and the first encryption protocol.

32. The client system of claim 31, wherein the first encryption protocol is a homomorphic-like method or Yao's algorithm.

33. A method for use in database operations on data associated with multiple parties, the method comprising:

providing, by a first user to a data processor, first data handling preferences associated with first transaction data stored in a database;

submitting, by the first user to the data processor, a query associated with an attribute of the first transaction data; and

receiving, by the first user from the data processor, a summarized version of a transaction data analysis, wherein the transaction data analysis is based on:

sensitive data elements associated with the first transaction data and second transaction data, wherein the second transaction data is stored in the database, the second transaction data inaccessible to the first user; and

an allowable operation determined by the data processor according to the first data handling preferences and second data handling preferences associated with the second transaction data, wherein the allowable operation is performed on the sensitive data elements; and

wherein the summarized version of the transaction data analysis comprises results of the transaction data analysis without reporting sensitive data elements associated with the second transaction data.

34. The method of claim 33, the method comprising providing, by the first user to the data processor, first data handling preferences associated with first transaction data stored in the database, wherein the first data handling preferences comprise at least one of a first operation preference or a first encryption protocol to be implemented on the first transaction data.

35. The method of claim 34, wherein the allowable operation is performed with the first encryption protocol.

36. The method of claim 34, wherein the second data handling preferences comprise at least one of a second operation preference or a second encryption protocol to be implemented on the second transaction data.

37. The method of claim 33, wherein the second data handling preference was provided by a second user.

38. The method of claim 37, wherein an identity of the second user is unknown to the first user.

39. The method of claim 34, wherein providing, by the first user to the data processor, first data handling preferences comprises selecting the first data handling preferences from a list of data handling preferences provided by the data processor.

40. The method of claim 39, wherein the list of data handling preferences comprises Yao's algorithm and a homomorphic-like method.

41. The method of claim 33, wherein providing, by the first user to the data processor, first data handling preferences comprises supplying, by the first user to the data processor, an encryption method previously unavailable to the data processor.