A targeted, yet privacy-friendly approach for battling poverty

In 2019 the Algemene Rekenkamer claimed that by estimation nearly half of the individuals that are entitled to AIO provision, a supplementary income provision for retired people, do not utilize it. The SVB, administer of the AIO scheme, desires to reduce this non-use by proactively approaching citizens that may benefit from the AIO scheme. A key challenge in this effort is to strike a balance between the benefits of the proactive approach and minimizing the privacy infringement caused by (1) selecting individuals that are to be approached, and (2) the actual approach of the selected individuals.

Aiming for maximal preservation of privacy, SVB initiated a collaboration with UWV and TNO in 2020 to come up with a solution that makes a well-founded, data-driven selection of individuals to be approached and complies with all SVB and UWV requirements regarding citizens’ privacy. The project, named BEATRICS, finished its proof-of-concept phase in March 2021 and followed up with a pilot phase.

SVB recently posted a blogpost that nicely describes context and purpose of the BEATRICS project, the structure of the project into phased, parallel technical and legal tracks, and the multi-facet processes of designing the right solution for the problem at hand. This blogpost complements the SVB blogpost by elaborating upon the cryptography-enabled solution for selecting individuals that are to be approached for AIO scheme.

Challenge: privacy-preserving selection of AIO provision candidates

Our hypothetical retiree Debra might be one of the individuals that is entitled to AIO provision. She can apply for the AIO provision if she meets all conditions that apply to the scheme. One of the most prominent conditions for the AIO scheme regards the joint net income (salary, pension, …) of Debra and other members of the Debra’s household (her partner Edward). Now, assuming that Debra is unaware of the AIO scheme, the challenge for the SVB is to identify Debra as a candidate for the AIO scheme while they don’t have insight into Debra’s nor Edward’s income.

If Debra were to apply for AIO provision, then the SVB would verify whether she met all conditions and determine the magnitude of the provision. At that point, Debra gives consent to the SVB for retrieving Edward’s and her gross income details from UWV. UWV would share those details and the SVB would start their verification by computing Debra’s joint net income and comparing it to the relevant threshold. If the SVB were to receive all the income details of Dutch citizens without their consent, then that would be a significant infringement of their privacy. However, if the SVB were to only get to know which households have an income lower than some threshold, then this moderate infringement could be acceptable if for a good cause.

The legal discussion about the proportionality of the infringement for a given cause is extremely relevant and currently ongoing – a reference to the outcome will be shared once available. Instead, this blogpost will describe how secure multi-party computation enables the SVB to learn only the outcome of the threshold comparison with Debra’s joint net income, whose details are known only to UWV, and nothing more.

Solution: Secure Multi-Party Computation

The dilemma of the SVB is a common challenge: a desire to collaborate and share information (in this case with UWV) while respecting privacy and confidentiality of the underlying data. A key observation in this dilemma is that the SVB is not interested in the data of UWV itself, but only in some processed or aggregated information that is derived from the data. As you might know, Secure Multi-Party Computation (MPC) is a collection of cryptographic techniques that enables organizations to derive those conclusions while protecting the sensitive data. We quickly take it one step further.

The MPC solution in BEATRICS is based on asymmetric, additive homomorphic encryption (HE). HE uses an asymmetric encryption system, implying that there are two keys: the public and the private key. The public key can be used to encrypt data, yielding a ciphertext, after which the private key can decrypt the ciphertext and recover plaintext data. Ciphertexts reveal no information about the plaintext data that was encrypted. Moreover, encryption involves randomness so that encrypting a fixed plaintext will yield a different ciphertext every time.

What renders HE different from traditional encryption schemes is that it supports certain mathematical operations on ciphertexts that are preserved in the decryption. More specifically, it supports addition and subtraction in the encrypted domain, as well as multiplication with a plaintext number. These two properties are crucial in the BEATRICS solution, which is based on a specific HE system: the Paillier cryptosystem.

The TNO MPC Paillier library is publicly available and, amongst others, provides functionality to precompute randomness in order to speed up the online phase of a Paillier-based protocol.

A threshold comparison protocol with the Paillier cryptosystem

The properties of the Paillier cryptosystem allow the SVB to securely evaluate the threshold comparison on the joint net income of Debra and Edward, whose income details are stored at the UWV. SVB determines which households will be checked, for example including only households with retirees and excluding households that already receive AIO. The list of individuals in the households are shared with UWV. The solution consists of four steps:

Note that a comparison of the encrypted joint net income with a threshold is much more complex than the addition of two ciphertexts, which the Paillier cryptosystem supports. Nevertheless, it is possible to perform the comparison, without revealing the inputs, by means of an interactive protocol in which one of the entities holds the secret key (UWV). The SVB and UWV exchange encrypted messages in several rounds of communication that concludes in a setting where only the SVB learned the result of the comparison. The UWV did not learn anything about the joint net incomes, the threshold, or the result of the comparison.

A simplified example: Suppose that the income can only be 0 or 1 and that the threshold value is 1. The SVB wants to know whether the income a is less than 1, but only the encryption [a] of a is known to the SVB. The SVB, in collaboration with UWV, can find out in the following way whether a < 1 without decrypting [a] directly. The problem can be reduced to the question whether a is equal to 0. The SVB can learn this (without UWV learning) by means of the following interactive procedure:

The SVB will share the value [y] with UWV, where y itself is not known to the SVB. First, SVB tosses a coin.

• In case of heads holds: [y] = [a].
• In case of tails the following applies: [y] = [1] [-] [a] where [1] is the encryption of 1 and “[-]” here stands for the homomorphic “minus”

UWV decrypts [y], resulting in y. UWV does not know whether SVB has thrown heads or tails, so does not know whether y=a or y=1-a. UWV then sends y to the SVB. SVB knows whether it was heads or tails: y=a if it was heads or y=1-a if it was tail. As soon as the SVB receives the value y from UWV, SVB can deduce what the value of a is.

This is a simplified example, but it illustrates how UWV cannot learn the value of a by helping to decrypt a masked value. This is essentially how the BEATRICS comparison protocol works.

The TNO MPC secure comparison protocol is now publicly available. It is based on an article which additionally proposes an enhancement that will soon be implemented and distributed. The enhancement requires an implementation of the DGK system; our implementation thereof will also appear on PyPI shortly.

The SVB-UWV communication for the proof-of-concept of version of BEATRICS and particularly the secure comparison protocol was handled by the TNO MPC communication library, which sends arbitrary Python data types over HTTP(S).

Results

The presented solution meets the requirements of both the SVB and UWV: the privacy of the citizens is protected and no new personal data is created by UWV. The homomorphic encryption solution is also expected to be compatible with the data exchange systems of SVB and UWV.

We developed a proof-of-concept and tested it with fake data. This proof-of-concept consists of two modules including a graphical user interface: one for the SVB and one for UWV. The proof-of-concept was installed on a machine in The Hague and one in Groningen to measure the efficiency of the solution. The calculation for a (synthetic) dataset with 8000 individuals takes less than 10 hours and scales linearly with the number of households. This is much slower than a regular data exchange, but fast enough for practical use. Moreover, several significant performance improvements are foreseen for the pilot phase.

Conclusions

The proof-of-concept has been successfully completed and meets the requirements. With an approved Privacy Impact Assessment and a legal basis, the BEATRICS project is proceeding to a pilot phase. During the pilot, the solution will be installed in an environment of the SVB and UWV and the aim is to identify about a thousand potential AIO candidates via MPC. By approaching these people, more insight is gained into whether the non-use of AIO can be reduced through the MPC approach.

The BEATRICS project shows how MPC techniques can ensure that the government can provide better services with proportional data processing. This allows governments to tackle societal challenges such as poverty and meet privacy and data protection requirements at the same time.

Want to know more? Contact us or read our ERCIM news article.