This project involved ASML’s collaboration with Psst to build new open-source tools that help whistleblowers verify their identities and share disclosures with trusted individuals in a way that better protects whistleblower privacy.
Vision
To build identity verification infrastructure that allows people to prove who they are without revealing unnecessary personal information – particularly in high-stakes scenarios like whistleblowing.
Goals
This project provides tools that
- Enable selective, verifiable identity disclosure.
- Encourage multiple voices to come forward without placing the first voice at risk.
- Put control of digital identity back in the hands of users, letting these users decide what to share and when, not the platforms or institutions they work for.
Why This Matters
Working together with Psst, ASML sought to create digital identity mechanisms that center decision-making authority with users themselves, not a third-party infrastructure provider. These new kinds of identity mechanisms would be particularly helpful for whistleblowers, who need to authenticate themselves (and share data via their authenticated identities) in high-stakes situations where privacy and security are paramount.
For example, consider a whistleblower at Company C who wants to initiate a conversation with an outside party (e.g., a journalist or regulator). The whistleblower needs to reveal the least amount of personal information that is sufficient for the outside party to verify the whistleblower’s employment; the whistleblower wants to reveal nothing else about their identity because premature exposure of their full identity might put the whistleblower at risk (legal or otherwise). Unfortunately, traditional authentication infrastructure (e.g., single sign-on via Facebook or email communication via Gmail) reveals personal information to the identity provider and/or the recipient of a message from the whistleblower.
How It Works
Guided by Psst’s experiences working with real-life whistleblowers, ASML designed new infrastructure for Psst’s digital safe. The safe functions as an “information escrow,” storing multiple reports involving the same company until a critical threshold of reports is reached, at which time the reports can be released together without exposing any single whistleblower too early.
We focused on building two new pieces of infrastructure: verification tools and matching tools. We describe each piece below and explain why these layers are useful in online communication scenarios besides whistleblowing.
Verification Tools
These tools allow an individual to prove their organizational affiliation (i.e., that they really work at Company C) without compromising anonymity. We created three such authentication methods.
Covert IP Identification: We used domain fronting to verify a user’s corporate IP address without revealing that the user is communicating with a Psst-run verification server. A prototype implementation of this technique is available now on our GitHub (#1, #2, #3).
Organizational Email Verification: We built two methods that enable users to demonstrate current or former ownership of an email address from the employer – e.g., an @company-c email address. First, we built a browser extension plugin, leveraging third-party email verifications (e.g., verifying your work email on LinkedIn or GitHub) and an open-source tool called TLSNotary. TLSNotary simulates how a human notary works for a traditional legal document, “observing” and attesting the authenticity of website data. Our plugin uses TLSNotary to attest that someone’s LinkedIn account lists a verified organizational email; however, the plugin does not collect a user’s name or other identifying information.
Second, we leveraged cryptographic email signatures (DKIM), which attest that the sender holds a valid organizational (e.g., @company-c) email address. We built an identity verification flow that generates an innocuous but unique “code” – a grocery list, in our version – for users to send from their work email address. Then, verifying servers use the DKIM signature to confirm that the email is legitimate and check that the content includes the unique code. A live demo is now available, and our code is publicly accessible on GitHub (#1, #2, #3).
Matching Tools
These tools ensure that sensitive disclosures are only released when multiple independent reports describe similar issues at the same company. A whistleblower tags a disclosure with a company name and issue type (e.g., “fraud,” “AI safety”). These “matching reports” are defined as reports tagged with the same issue type and same company.
The Rendezvous Protocol end-to-end encrypts disclosures sent to a recipient, and uses threshold cryptography to split each encrypted disclosure into fragments that are distributed across independent servers. Those servers will only release the fragments to the intended recipient when a threshold number of matching disclosures have arrived. A prototype end-to-end implementation of this protocol is available now on GitHub (#1, #2, #3), alongside a white paper that outlines in detail how someone like Psst can use the protocol.
Trusted Execution Environments (TEEs) leverage secure hardware within a computer’s processor to isolate sensitive computations, preventing other applications on that machine (even the operating system) from examining the activity of the computation. A computation running inside a TEE can also cryptographically demonstrate what code the computation is running, allowing an outside entity to be confident that the computation will securely process sensitive data. In the context of whistleblowing, this “remote attestation” facility allows whistleblowers to verify that their disclosures are being sent to a trusted enclave that correctly follows the cryptographic Rendezvous Protocol.
Combining TEEs with distributed cryptographic protocols like the Rendezvous Protocol, we can build more resilient, pluralistic trust models that don’t rely on all actors to behave perfectly.
Who Can Benefit
These building blocks can support anyone who has to build trust under conditions of partial anonymity, including:
- Whistleblowers seeking safety in numbers
- Activists and vulnerable groups operating under threat
- Journalists verifying sources
- Content creators proving who they are on social platforms.
Get Involved
We’ve built modular components that can be adopted and extended by other communities. We want to hear from you! For example, we would love to hear from:
- Newsrooms that want to empower source-safe reporting
- Labor and advocacy orgs who need support for collective disclosure
- Academic or legal researchers working on privacy, anonymity, or digital identity
- Platforms and toolmakers looking to add privacy-preserving verification to existing workflows.
If you’re building a system that requires provable privacy guarantees, or if you’re making a platform where safety in numbers could unlock a story that would otherwise stay hidden, please contact us at asml@cyber.harvard.edu.
Our work is open-source and available on GitHub (#1, #2, #3).
Learn More
Read the full story of our collaboration with Psst in Selfhood in the Shadows: Rethinking Whistleblowing Infrastructure with Psst.
Team
