Designing safe digital systems for the humanitarian sector

Carmela Troncoso details a multi-year collaboration with the International Committee of the Red Cross (ICRC) to digitalize their aid distribution process. The core challenge is to move away from slow, error-prone, and difficult-to-audit paper-based systems without introducing new risks to vulnerable aid recipients.

The Flaw in Traditional Privacy Models

A straightforward digitalization, such as creating a central database, is fraught with peril. The data collected is extremely sensitive, and history has shown that even trusted organizations can be hacked or forced to surrender data. A stark example is when the Taliban gained access to biometric databases left behind in Afghanistan, which were then used to persecute people.

The common approach in the privacy community is to focus on data confidentiality through encryption, differential privacy, or trusted execution environments. However, Troncoso argues this misses the point.

“Privacy is not really about protecting data. It’s really about protecting people from the consequences of using the data.”

Confidentiality alone does not prevent misuse if an adversary gains control of the entire system. The true goal should not be data minimization but purpose limitation: designing systems that can only be used for their intended function and nothing else. The data should be stored in a form that is inherently non-repurposeable.

This was the core principle behind the design of the DP-3T contact tracing protocol, where the public database of codes was “impossible to do anything else with.”

A Methodology for Purpose-Limited Design

To build such a system, Troncoso’s lab follows a specific methodology based on deep engagement with the partner organization:

1. Determine the System’s Purpose: Instead of asking stakeholders what they want or need (which often leads to replicating existing flawed processes), the team asks, “What do you do in your day?” By understanding the daily workflow and asking “why” at each step, they extract the essential functionality. This opens the design space to novel solutions that users wouldn’t have conceived of, especially those involving non-intuitive cryptographic primitives like zero-knowledge proofs.
2. Collaborative Threat Modeling: Rather than asking for a formal threat model, they ask, “Who might interact with the system?” and “What harms could happen to people if information is available to different parties?” This process, combined with studying ICRC documentation, builds a practical understanding of the risks.
3. Identify Fundamental Leakage: Any useful system must reveal some information to function. For aid distribution, the field agent must know what goods to give a person. This “fundamental leakage” defines the system’s inherent risk. Acknowledging this helps in two ways: it forces a conversation about whether the system’s purpose is worth the inherent risk, and it simplifies the technical design by clarifying which data doesn’t need protection because it will be revealed anyway.

System Design: Decentralized, Low-Cost, and Resilient

The collaboration produced a system designed around the ICRC’s real-world operational constraints: low cost, minimal to no connectivity, and the need for robustness.

The final design avoids a central database and instead operates in a decentralized manner using cheap smart cards (costing a few cents).

System Phases:

1. Registration: Aid is often distributed per household, not per individual. At registration, a household receives one or more smart cards. This phase is assumed to be honest; if fraudulent identities are registered, the system cannot prevent fraud.
2. Distribution: An aid recipient presents their card at a distribution station.
3. Audit: The ICRC must provide proof of distribution to donors for transparency and continued funding.

Technical Implementation:

• The Smart Card: Each card acts as a decentralized database entry for a household. It stores:
  • A symmetric key unique to the household.
  • The household’s aid entitlement (e.g., “3 bags of rice, 1 bottle of milk”).
  • A counter for periodic distributions.
• The Distribution Process:
  1. The recipient authenticates to the card (e.g., via biometrics stored only on the card).
  2. The card reveals the specific entitlement to the distribution agent (the fundamental leakage).
  3. To prevent double-dipping, the card outputs a tag (a hash of the household’s secret key and the current distribution period). All cards from the same household produce the identical tag for that period. The station simply checks if it has seen this tag before.
  4. The card provides a digital signature on its output to prove it is a legitimate card issued by the ICRC.
  5. For auditing, the card outputs a homomorphic commitment of the entitlement. These commitments can be summed up by the auditor to get a total of all distributed goods without revealing any individual’s entitlement.

The central list maintained by the distribution station is just a collection of random-looking tags and homomorphic commitments. This data is useless for any other purpose, achieving the goal of purpose limitation.

Extensions and Further Work

The initial system was extended to address more complex needs:

• Wallets for Vouchers: For cash or voucher programs, the system was adapted into a wallet. It uses an ORAM (Oblivious RAM), where the recipient’s card itself synchronizes the state between different vendors in an oblivious manner.
• Privacy-Preserving De-duplication: To prevent individuals from registering with multiple households, a system for biometric de-duplication at registration was developed. It provides only a one-bit output (“registered” or “not registered”) and includes a kill switch. This allows the ICRC headquarters in Geneva to remotely deactivate the checking function, preventing the system from being used as an oracle by an adversary who seizes the equipment.
• Assessments and Statistics: To meet donor reporting requirements and the ICRC’s “duty of care” (e.g., checking on families who miss distributions), a system for generating statistics was created. This was a difficult decision as it introduces more leakage. The solution uses one-time functional encryption, allowing the computation of a specific statistic (e.g., “percentage of pregnant people who received aid”) only once per query. It also includes safeguards like thresholding, which only returns an answer if the group size is above a certain minimum to prevent deanonymization.

• Tags:
• Feature
• Cryptography
• System Design
• Threat Modeling
• Privacy-Enhancing Technologies
• Humanitarian Aid
• Purpose Limitation