Technical Measures for Schrems II

How to use encryption to create appropriate safeguards for EU personal data

The Complexity Of Holding 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.

All Eyes On Meta

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.

The Recent Trans-Atlantic Data Privacy Framework Announcement

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:
  1. 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.”
  2. Under the order, U.S. agencies will adopt new unspecified procedures to ensure effective oversight of privacy.
  3. 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.

Experts Remain Skeptical Of New Framework

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.”

Avoid Gray Areas With Technical Solutions

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.

Schrems II Encryption Patterns

End-to-end Encryption

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.

Benefits of Encryption Solutions

Schrems II FAQ

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.
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.
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.
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.
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.
Probably not.
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.
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.
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)
  • Arguably stronger than HYOK, end-to-end encryption means the service provider never has access to the unencrypted private data and couldn’t store it off on their servers. However, if they can be compelled to change their software, that includes the software that runs on the client (eg, JavaScript in a browser) where the decrypted data is seen, so again, even E2EE is undermined here.
Cloud access security broker (CASB)
  • For years there have been systems that act as proxies that intercept API requests and modify them to encrypt outbound data and decrypt inbound data. These systems tend to be very brittle and cause all sorts of breakage in the cloud software. They’re expensive to maintain and they may undermine security by preventing monkey-in-the-middle attacks. They’re seeing some new life recently because of Schrems, but in fact they’re subject to the same issues as HYOK and E2EE – if a U.S. company can be compelled to build backdoors and has control over the client-side software (eg, JavaScript in the browser), then their code has access to decrypted data and could potentially upload it somewhere.

Talk To Us About Schrems II Solutions

Products

Documentation

Trust Center

Find Us