psi-pilot-masstech
This pilot project for MassTech provides two different solutions to handle Private Set Intersection or Private Membership Testing to enable bank fraud detection. In this banks can query each other's list of fraudulent customers, while only learning if their query is a match or not.
The first solution is a peer-to-peer setting where banks communicate directly with each other, which is more straightforward to implement but requires banks to be online when a different bank wants to query their data. It also incurs a higher bandwidth cost for participating banks when updating their records. The second version enables banks to securely outsource the computation to a different set of non-colluding parties, which allows them to only be online when they update their list of fraudulent customers. The computation is then performed by two or more compute parties, who only learn the size of the list of fraudulent customers, and how often a query is performed. Both versions assume a semi-honest model, i.e. where no parties deviate from the prescribed protocol.
Peer-To-Peer
Testing
Required Files
Firstly you will need to create a .env file that contains two values. The first is a value named SHARED that can be any string and represents the secret value both parties should have in order to query one another. The second is a value named KEY that should be set equal to a hash of a valid scalar generated by the oprf library. You will need two copies of this file, one placed inside of the p2p directory, and one in the project's top-level directory.
Next you will need 3 config files. The first two should be placed in the config folder inside of the p2p directory. One should be for the server acting as the querier and one acting as the list-holder. All that needs to be specified in these is the "domain", "holderDomain", and "port" values. These should be different for the two servers. The final config file should be in a config folder that is in the project directory. Your testing config file should be called "test.json" and should have the same values as your querier config file.
Running the Test
First you have to get your two servers running. Inside of the p2p directory, run node p2p.js --config=listHolderConfig and in another console run node p2p.js --config=querierConfig where listHolderConfig and querierConfig are replaced with your config file names (without the .json). Now just run the command npm test -t p2pAPI.test.js in order to run the p2p tests.
Demo Steps
Required Files
The same two querier and list holder config files are needed as with testing, except now you will probably want to add "display": true to both of them. You can also specify the data you want to be queried in the querier list by creating a queryData object in the config file. The same goes for the list holder; You can specify some of the values that will appear in the table by creating a list called tableData in the list holder config file
Running the Demo
First you must get your servers up and running again like with testing, except this time use the different demo config files you created. Instead of running the test command, however, you will instead run the following commands inside of the p2p directory: node demo.js --holder --config=yourDataConfigFileName and node demo.js --querier --config=yourQuerierConfigFileName. The first command will populate the list, and the second will do the queries to the list, finding any intersections.
Outsourced#
Testing Steps
Required Files
You do not need any .env files for the outsourced implementation. First choose how many compute parties you want there to be and create a config file for them in the config folder inside of the outsourced directory. For list creators do the same thing, decide how many creators you want and make a config file for each of them. Each of these should contain unique values of "domain" and "port" and two lists called "computePartyDomains" and "creatorDomains" that are a list of all the CP and creator domains. Each of the compute party config files needs a list called "testKeys" that contains about 15 strings (these are used to mimic randomized keys throughout the tests). Finally, you should make a config file called "test.json" in the config folder in the project's top-level directory. This should contain the "computePartyDomains" and "creatorDomains" lists, and a list called "testKeys" which is a list of the "testKeys" lists in the CP config files (these should be in the same order as teh computePartyDomains list);
Running the Test
First you have to get all of your servers running. Run the command node outsourced.js --test --config=configFileName for every server you want running where configFileName is replaced by their config file name (excluding the file extension). The --test flag can be excluded for list creator servers. Now run the command npm test -t outsourced.test.js to run the tests for the outsourced implementation.
Demo Steps
Required Files
Look at the *.example.json files in the config folder for a potential configuration. In this instance we have one data contributor, one query party, and two compute parties.
Running the Demo
First run all of your servers again. For all data holders, compute parties, and query parties, you will just run node outsourced.js --config=configFile replacing configFile with their respective config file names. Run the following command to distribute the secret shares between the compute parties: node demo.js --create --config=data1.example. At this point you can terminate the data server. Finally have the query party server connect to the compute parties to find the overlap in records: node demo.js --query --config=query1.example.