Technical Measures for Schrems II
How to use encryption to create appropriate safeguards for EU personal data
The data of EU citizens can only flow to nations that have adequate privacy protections. The U.S. does not gurantee privacy to any non-U.S. citizens, which conflicts with EU constitutional privacy guranatees and GDPR.
As a consequence, agreements between the U.S. and EU have repeatedly been struck down. Most recently, the EU-U.S. Privacy Shield Framework was struck down in a case called Schrems II.
In 2020, when the Court of Justice of the European Union ruled that the framework was invalid, they cited U.S. intelligence overreach and the lack of redress options for EU citizens. That left U.S. companies once again without a legal basis for holding EU personal data.
The rollercoaster ride of data protection agreements and policies has led to uncertainty, lost business, and numerous lawsuits seeking to halt U.S. software companies from doing buisiness in Europe.
Not long after the EU-U.S. Privacy Shield was struck down in 2020, the Data Protection Commission (DCP) sent Facebook, now Meta, a preliminary order telling Facebook to suspend data transfers.
Two years later and Meta’s best lawyers are still dragging things out to avoid facing a ruling that could force the company to stop operations in the EU.
Meta’s best hope was for a new framework to appear that would create a legal basis for operating in Europe and make the case against them moot.
On March 25, 2022, the U.S. and EU agreed “in principle” on a new legal framework for GDPR-compliant data transfers, with extra emphasis on “in principle.” Very little is known at this time about what this framework might entail or how it would work. All we have are bullet points:
- A new executive order will instruct U.S. intelligence agencies to only access the data on EU citizens if that access is “necessary and proportionate to protect national security.”
- Under the order, U.S. agencies will adopt new unspecified procedures to ensure effective oversight of privacy.
- The order will also create a redress system by which Europeans can make privacy complaints that will be investigated and resolved by a new undefined “Data Protection Review Court” that will be staffed by people who are not a part of the U.S. government.
This is yet to be solidified and will certainly be challengened.
It’s no surprise that, after all the many ups and downs over the years, the software industry and legal experts are skeptical of the Trans-Atlantic Data Privacy Framework getting approval and surviving a challenge.
Max Schrems, lead litigant in the “Schrems I” and “Schrems II” cases before the CJEU, released his initial reaction to the Trans-Atlantic Data Privacy Framework announcement and had this to say:
"We already had a purely political deal in 2015 that had no legal basis. From what you hear we could play the same game a third time now. The deal was apparently a symbol that von der Leyen wanted, but does not have support among experts in Brussels, as the US did not move. It is especially appalling that the US has allegedly used the war on Ukraine to push the EU on this economic matter.”“It is regrettable that the EU and US have not used this situation to come to a 'no spy' agreement, with baseline guarantees among like-minded democracies. Customers and businesses face more years of legal uncertainty.”
If you’re like us, you might be frustrated with the uncertainty that politics and court cases have inflicted on everyday business. So let’s get to the core of the issue. What can US software companies do to comply with the EU expectations of privacy and data protection? Standard contractual clauses are certainly recommended, but to really satisfy the core issue, US software companies need to protect data from U.S. government overreach.
Encryption, when used appropriately, safeguards access to EU personal data by ensuring due process that meets EU privacy standards. One way to achieve this is to make U.S. government agencies work with their counterparts in the EU to get access to EU personal data.
There are two encryption patterns that accomplish these goals.
Data is encrypted and decrypted on user devices, and the software companies holding the data don’t have access to the keys needed to decrypt it. Their servers never see anything but meaningless bytes.
A government agency wanting access to the data will either need to compel it from the data owner, gain access to an authorized device that holds the key, or otherwise break or undermine the system.
Bring Your Own Key
Data is encrypted before being sent to the database or disk and the software company does not hold the keys needed to decrypt sensitive customer data.
For this to be effective, BYOK must be implemented in such a way that a U.S. agency would have to compel the software company to write code that undermines their access controls and security measures to get access to the unencrypted data.
Do you need to have a European company as a partner to protect EU personal data?
No. That is one way you could potentially protect EU personal data from compelled access that bypasses EU privacy protections, but it is not the only way.
Can encryption be used to protect EU personal data held by US companies from compelled access that bypasses EU privacy protections?
Yes. In protecting the data such that data subjects' rights are preserved, it does. The European Data Protection Board also explicitly notes that encryption keys staying inside the EU is a way to manage access issues. Any encryption scheme attempting to solve this problem needs to meet these criteria:
- The private data is meaningfully encrypted – meaning at the application layer so that fetching data from a database returns encrypted values, which is what would be produced in case of a warrant.
- The key(s) for decrypting the data remain within the EU or trusted third countries, meaning that to gain access to the keys, legal processes must be used that protect the privacy of EU citizens. Implied in this is that the U.S. company holding the encrypted data can’t produce the keys to decrypt the data since those keys are held by another party such as the customer.
- Not mentioned, but of equal importance: the software vendor may be able to decrypt data on their servers for various purposes, but they should not have a way to view or export the data in an unencrypted form.
Do you need keys to be stored by an EU company in the EU?
The European Data Protection Board provided guidance suggesting as much, but they also haven’t specifically evaluated a lot of scenarios that likely provide equivalent protection:
- For example, Amazon claims they can’t produce unencrypted keys due to how their systems are designed. The master keys they hold are generated and held by hardware security modules and can’t be extracted from those. Subkeys are encrypted with those inaccessible root keys.
- Some cloud providers also support making calls out to remote KMSes. For example, Google Cloud Platform has an integration with Thales that allows a Thales appliance to be the root of trust and to hold the master key that is needed to unlock other keys in the system.
The safest thing would be to use an EU KMS provider in some form.
What if a U.S. FISA court tries to compel access?
For IronCore Labs:
- We don’t have any data of value – not that we can decrypt – so it’s unlikely they’d do this.
- If they should anyway, we’ll respond appropriately to lawful requests, but that means delivering back encrypted data.
For our customers:
- As long as the data you pull off of disk or out of a database is encrypted (because it was encrypted before being sent to the data store using application-layer encryption) and as long as you can’t produce the keys, then complying with a court order means producing data that is encrypted, which poses no harm to EU citizens.
If a company can access a KMS to decrypt the data it holds, can’t a court mandate that they use that access to produce the data?
Not if the company doesn’t have a way already built into their software to extract the decrypted data.
In a properly designed system, the only way to produce the decrypted data would be to write software that decrypts it and writes it to disk. This should go against contractual promises, which means the U.S. government would have to have the power to compel a software company to build a backdoor that undermines its own security system.
Can the U.S. compel a U.S. company to add a backdoor?
It all hinges on a phrase from the All Writs Act that the FBI tried to use to compel Apple to undermine its product security. That clause says that telcos must provide “reasonable technical assistance” to help obtain data. Apple challenged this with a number of compelling arguments (including one about code being protected free speech that can’t be compelled, which was a novel and interesting defense and another about the unreasonableness of a government having this power where they could next order all microphones on so the government can listen in). The FBI backed down.
There is no clear definition of “reasonable,” but we believe that any request that forces a company to destroy its own business is unreasonable and the resulting effect would be that U.S. software companies would no longer be able to compete in the global marketplace. It would be devastating.
But what if they brought huge resources to bear and swamped IronCore Labs or others with secret legal battles requiring deep pockets to fight?
We believe any attempt to force us (or our partners) to change their software to weaken security is illegal and as such, we’ll fight such requests. That means we’ll use all of our resources to fight it and we’ll ask for assistance from organizations like the EFF and ACLU for help in fighting such requests.
What different technical approaches could protect the data?
Hold Your Own Key (HYOK)
- A hold-your-own-key approach where EU customers hold their own keys (perhaps via an infrastructure provider) or where an EU entity holds the keys for them will protect the data unless the U.S. can compel software companies to write backdoors, which is not a power they explicitly hold today.
End-to-end encryption (E2EE)
Cloud access security broker (CASB)