Privacy-Preserving Vaccination Checks: A Proof of Concept MPC Deployment with the Frankfurt Health Department

This work is part of the ATLAS project on data trustees for anonymized analysis in municipal data spaces. A great write-up by Polyteia regarding other evaluated use cases, which did not progress to a pilot stage, is available here.

The German measles protection act, introduced in 2020 with a transition period until 2022, requires children in daycare/school and workers in specific facilities to be vaccinated against measles. If a proof of vaccination is not provided, the responsible health department is notified. The health department tries to contact the person or their legal guardians to procure the proof of vaccination. If none is provided, the department can summon them for a consultation. In cases of continued refusal to provide a proof of vaccination, the health department can issue fines and bans on entering or working at relevant facilities.

Now, there are children for whom no proof of vaccination has been supplied to satisfy the new measles protection act, even though a vaccination has been previously recorded during their school entry examination (ESU). This could be due to forgetfulness, a misunderstanding, or a reporting issue. These cases needlessly increase the work and costs associated with the enforcement of the protection act.

The Frankfurt health department, as part of their GA-Lotse project, wants to identify those cases where they already have knowledge of a measles vaccination from the ESU. The protection procedures and ESU data are stored in two separate modules with a strict separation of concerns. Joining this data is subject to strict regulations. While the health department has the legal basis to do this processing of the joined data in plaintext, they want to go one step further by utilizing state-of-the-art cryptographic tools. Using secure multi-party computation (MPC), a type of cryptographic protocol, we can process these two separate data sets while minimizing the data that needs to be brought together. It allows us to check whether a child, for whom an open protection procedure exists due to missing proof of vaccination, has had a vaccination recorded as part of the ESU. This is done without exchanging the data in clear, but by computing on encrypted data.

Together with the Frankfurt health department, Polyteia, and cronn, we have developed a proof-of-concept of this system for the GA-Lotse software project using our MPC engine Polytune.

Summary Poster

This poster was presented at the AnoSiDat 2025 conference and provides a summary of the project.

Secure Multi-Party Computation

Secure multi-party computation (MPC) allows multiple distrusting parties to jointly compute a function on their private inputs without revealing these inputs to each other. The parties achieve this by executing a cryptographic protocol amongst them, at the end of which they receive the output of the function, but have learned nothing about the private data of the other parties¹.

In essence, an MPC protocol can replace a trusted third party. Instead of sending their private data to some central entity, the parties encrypt their data and split it into a number of so-called “shares” (represented by locks in the diagram), where each share reveals nothing about confidential data. The parties exchange these shares of their data, so that everyone has a share of each other’s private inputs. To evaluate the desired function, it is first converted into a logical circuit consisting of AND and XOR gates². The parties together evaluate the circuit with their secret shares and in the end receive the result of the computation.

GA-Lotse: Measles protection and school entry examination data

Before you can use MPC, you first need data that is held by multiple parties, which cannot be shared between these parties in the clear, but on which you want to compute something interesting. The GA-Lotse project provided an interesting use case for the validation and test deployment of our MPC implementation. The GA-Lotse software is split into multiple modules with a strong focus on privacy, security and minimizing trust — even among modules. The interesting modules for our use case are the measles protection module, the school entry examination (ESU) module, and the base module. Their documentation and source code is publicly accessible on GitLab.

Measles protection module This module stores information about measles protection procedures. A user of the GA-Lotse software creates a new procedure in this module for children where no proof of vaccination was provided.

School entry examination module The ESU module contains data from school entry examinations, including whether children were vaccinated against measles at the time of the examination.

Base module This module is responsible for storing personal data. It manages file state IDs for every person and every module which contains data on this person. A file state ID is a universally unique identifier (UUID) for one person’s data in one module. E.g., person A might have the ID X0A… in the measles module, but ID B6E… in the ESU module. Each module should know as little as possible about the file state IDs of a person for other modules.

A concrete functionality

Given the data that is present in the different modules, how can we perform the vaccination check for a person when a new procedure is created in the measles protection module?

The idea is to perform a set intersection of all file state IDs known for one person with all IDs of vaccinated persons known by the ESU module. When a user creates a new procedure, the measles module requests all known file state IDs for this person for all modules from the base module. This is only a short list of UUIDs and contains no information as to which ID corresponds to which module. This list of IDs is checked against the IDs of the vaccinated persons from the ESU module using Polytune, without actually exchanging these IDs in the clear. The result can be a simple Boolean value, True or False, indicating whether there was a measles vaccination recorded for this child during an ESU examination.

Vaccination check in Garble

Garble is a domain-specific language (DSL) we have developed as a convenient way of specifying a function to execute using an MPC protocol. The syntax and features of the language are inspired by Rust, featuring variables, functions, loops, structs, enums, static typing and even pattern matching. Contrary to most compiled languages, the output is not an executable program, but a binary circuit comprising XOR, AND, and NOT gates. The MPC protocol implemented by Polytune is defined for such a binary circuit, computing the output of the function represented by the circuit jointly among several parties without revealing the inputs.

How can we do the vaccination check using Garble? The goal is to intersect two sets of file state IDs (16 byte UUIDs) and check whether there is an overlap. The set sizes are severely unbalanced, with the number of IDs coming from the measles module being in the range of 1 to 5, and around 6000 IDs coming from the ESU module. Therefore, the simplest way is also the fastest. By doing a pair-wise equality comparison of all possible pairs in the two sets and accumulating the result into a Boolean, we can calculate whether there is a match between the two sets with a low number of AND gates. For a check between set sizes 5 and 6000, the Garble program compiles to a circuit with ~3.8 million AND gates (127 AND gates per equality comparison and one per OR operation)³.

The program below accomplishes that using Garble. The constants declared at the top are constant dependencies and supplied by the computing parties before the compilation. They are part of the Policy supplied to Polytune by the connector component.‍

/// These constants can differ per computation and are exchanged in the clear
/// by the computing parties before the compilation of the program.
const ROWS_0: usize = PARTY_0::ROWS;
const ROWS_1: usize = PARTY_1::ROWS;
/// In practice, this is 16, as file state IDs are UUIDs.
const ID_LEN: usize = max(PARTY_0::ID_LEN, PARTY_1::ID_LEN);

/// A garble program that checks if any element in `measles_procedure_file_state_ids`
/// is in `vaccinated_file_state_ids` as well. If yes, the program returns `true`,
/// otherwise it returns `false`.
pub fn main(
// File state IDs from the measles module for one open procedure
measles_procedure_file_state_ids: [[u8; ID_LEN]; ROWS_0],
// File state IDs from the ESU module of all vaccinated children.
vaccinated_file_state_ids: [[u8; ID_LEN]; ROWS_1],
) -> bool {
pairwise_check(measles_procedure_file_state_ids, vaccinated_file_state_ids)
}

pub fn pairwise_check(
measles_procedure_file_state_ids: [[u8; ID_LEN]; ROWS_0],
vaccinated_file_state_ids: [[u8; ID_LEN]; ROWS_1],
) -> bool {
let mut is_vaccinated: bool = false;
for procedure_file_state_id in measles_procedure_file_state_ids {
for school_exam in vaccinated_file_state_ids {
is_vaccinated |= (procedure_file_state_id == school_exam);
}
}
is_vaccinated
}

Deploying Polytune

With the functionality decided and implemented in Garble, the next part is the actual deployment of the MPC technologies and their integration into GA-Lotse software. This was done with the help of Polyteia and cronn. While Polytune can be adapted for a variety of different use cases, its generality also requires there to be some “glue code” between where the data is and Polytune itself. This was developed as a connector component by Polyteia, translating the data from the GA-Lotse APIs into the required data types for the MPC evaluation.

The above diagram shows the (simplified) parts and flow of data between them for checking the vaccination status in a privacy preserving way using Polytune.

As a first step, a user of the Frankfurt health department measles protection module creates a new protection procedure for a child. This happens if no proof of vaccination is supplied to satisfy the requirements of the newly enforced German measles protection act.
The measles protection module requests all file state IDs for this person (UUID pseudonyms) for all modules from the base module. This set of file state IDs is passed to the measles connector with a request ID.
The measles and ESU connectors (developed by Polyteia) are the bridge between the specific data types and APIs offered by the health department and the generic secure computation service Polytune. After receiving the file state IDs, the measles connector notifies the separate ESU connector of this request. The file state IDs are not transmitted to the ESU connector, but only that a new vaccination check has been requested with the specified request ID.
The ESU connector then retrieves the set of file state IDs corresponding to all vaccinated children from the ESU module. It does not retrieve only the specific data for the child relevant to the request to the measles connector. In fact, it could not request that, as it never has access to that information.
Both connectors use their sets of file state IDs as the input for a Polytune Policy, which specifies the Garble program to execute, the participating computation parties, one’s own inputs, and necessary constants for program compilation. The Garble program checks whether there is an element in the intersection of both file state ID sets. If yes, the child is vaccinated, and the program returns true.
Once both Polytune instances receive their Policy, they validate and execute it. The evaluation of the program is performed using the secure multi-party computation protocol published by Wang et al. [WRK17b]⁴. This includes a compilation of the provided Garble program for the concrete values of the ROWS constants.
Once the Polytune instances finish the secure computation, the instance assigned to the measles connector sends the result, a single Boolean indicating the vaccination status, to the connector.
The measles connector passes along the result of the vaccination check to the measles module. As the computation can take up to multiple minutes, the measles module periodically queries the connector for the computation’s state. While this latency is higher than with normal processing, it is reasonable for this administrative process. In most cases, it just takes a couple of seconds.
Finally, the result of the vaccination check is displayed to the user for the created protection procedure. The administrative burden can be reduced if the system verifies that a child, currently lacking proof under the measles protection act, already provided this proof during a previous school entry exam.

The measles connector/Polytune instance as well as the ESU connector/Polytune one were each deployed in their own Kubernetes pod. To authenticate and secure the communication going from one pod to another (3, 4, and 5 in the diagram) cronn developed a gateway that authenticates and encrypts all communication using mTLS. This gateway is part of each Kubernetes pod and the connector and Polytune instance within the pod authenticate themselves to the gateway using signed JWTs.

Why not something simpler? While this specific use case could have been implemented using a specialized protocol, the strength of general-purpose MPC lies in its universality. Because MPC can compute any function representable as a circuit, it can be easier to deploy than a custom-built solution. Our hypothesis is that for many public-sector use cases, the performance cost of a general MPC protocol is a reasonable trade-off for the standardized ease of deployment and integration it offers. This pilot use case allowed us to build the foundation for a flexible and reusable MPC platform.

Learnings

While there are many problems where MPC could be an invaluable tool in gaining insights from otherwise inaccessible data, there are still significant hurdles for real-world deployments. At this time, integrating MPC into an existing software requires a substantial investment. We are still on the path towards seamless usage of MPC, but not there yet. Additionally, legal questions on how MPC should be viewed under the GDPR have not yet been fully resolved. This creates legal uncertainty and roadblocks for employing MPC for critical data. In the case of the Frankfurt health department proof-of-concept, this was possible as there was a legal basis for plaintext joining and processing of the relevant information. The people involved in the GA-Lotse project were interested in how MPC could be used to further data minimization and zero trust principles.

Of interest to MPC practitioners is that the involved parties of a secure computation don’t necessarily need to be controlled by different entities. In this pilot, the two computing parties are different software modules of the GA-Lotse software. While unconventional for MPC, this still provides a benefit from a perspective of minimizing data that is processed in one place and reducing necessary trust between systems. MPC can be a tool for the secure internal processing of data as part of a defense-in-depth approach.

This pilot integration of Polytune into the GA-Lotse software required a new Polytune server software which we developed alongside and informed by the use case. It is responsible for the coordination of the computing parties before the start of the actual MPC computation.

Outlook

Although MPC is fairly established in the scientific literature, its real-world application is just at the beginning. We believe that MPC, paired with strong governance structures, could unlock significant benefits and knowledge from data silos in a secure and privacy-preserving way.

Do you have similar use cases where you want to collaboratively compute on encrypted data? Reach out to us at vorstand@sine.foundation!

Want to have a look at the nitty-gritty details? All our work is open-source and available on GitHub. Have a look at our Garble language or our Polytune engine (written in Rust 🦀), try it out, file issues, let’s collaborate!

‍

Related Library Posts:

Footnotes

1: The parties learn nothing about the other’s private inputs apart from what is revealed by the function’s output itself. If you compute a sum between two private numbers $a$ and $b$, then knowledge of one of these numbers and their sum $y = a + b$ necessarily leaks the other number. Thus, MPC can leak some information about private inputs when computing “trivial” functions.

2: The terminology of circuits and gates for MPC protocols comes from the academic literature on this topic where the protocols are often defined as operating on a simple topologically sorted list of gates connected by wires. These are not actual hardware circuit, but only a representation of a function. Some frameworks like MP-SPDZ and Polytune represent the function as list of bytecode instructions for a specialized virtual machine that implements the MPC protocol.

3: This is fewer gates than using a bitonic merger network (built into Garble), which scales better asymptotically, but is worse for these concrete numbers.

4: The protocol by Wang et al. [WRK17b] is a distributed authenticated garbling protocol offering security against up to N - 1 malicious adversaries. Even if every party but one tries to actively break the protocol, they cannot learn anything about the private inputs of the honest party.

Acronyms

MPC: secure multi-party computation ESU: “Einschulungsuntersuchung” the German school entry examination, where vaccinations and other health markers are recorded by a doctor.

References:

https://www.bundesgesundheitsministerium.de/impfpflicht/faq-masernschutzgesetz.html

This work was part of the “ATLAS: Data trustees for anonymized analysis in communal data spaces” project funded by the Federal ministry of Research, Technology and Space of Germany.

‍