Can Teaclave resist Multi-query Attack?

[bobozi-cmd]

Hi! I am interested in the way to resist Multi-query Attack. The multi-query attack method includes two attack ways: (1) One way to obtain the other party’s information is to tamper with the input content for each query, while keeping the query itself unchanged. For example, the attacker can obtain all the information of the other party’s join key through multiple join queries and tampering with the content of his join key each time. (2) Another way is to infer the other party’s private data by rewriting the query each time and comparing the results of multiple queries. For example, the attacker can use the where condition to limit the input of the aggregation function. The first time the query obtains the aggregation result of N pieces of data, the second time by changing the where condition, the aggregation result of N-1 pieces of data can be obtained, and then the attacker can obtain the original information of 1 piece of data by comparing results. Cam Teaclave help user resist this attack automatically? Thanks!

[henrysun007]

The short answer is no but it could be implemented. I would answer the question more accurately and in detail if you could give more description about the motivation and threat model. It seems not necessary to resist the attack.

[bobozi-cmd]

A simple case is: SELECT SUM(money) FROM table; SELECT SUM(money) FROM table WHERE id<>1; than I can compute the money of user 1

[henrysun007]

Since you can SELECT the table, why not use SELECT money FROM table WHERE id=1 to get the money of user 1 directly?

[bobozi-cmd]

One condition is that attacker cannot select plaintext from table， but can select result of some operations like SUM, AVG etc. For protection someone‘s data, DB will filter result after SQL to avoid data source only one row. Attacker may not know any data in DB, but can use == to guess existed id and use SUM(n) and SUM(n-1) to compute target data.

[hiroki-chen]

I wonder why Teaclave needs to support such attacks because it seems to me that these threats are orthogonal to Teaclave's design goals. The attacks themselves, essentially, fall into the category of side-channel and statistical inferences that can be found in the DB research area.

[bobozi-cmd]

these threats are orthogonal to Teaclave's design goals

yes, I realize this now, and thanks for your suggestion :)