On July 16, 2020, the European Court of Justice invalidated the EU-US Privacy Shield Framework, erasing the data protection measures that had previously allowed a United States business to hold the data of European Union citizens in servers that reside in the US. The data residency implications are serious. In the face of legal uncertainty, businesses are at risk of a court ordering them to stop transferring data to the US or other non-EU countries. However, while we wait for legal clarity, it’s clear that businesses can meet EU standards by encrypting the personal data of EU citizens in a way that meets EU standards for privacy, regardless of where the data is stored. This article will introduce three technical approaches to handling EU Data without a privacy shield. Background on the Schrems Case The lawsuit that invalidated the Privacy Shield Framework was brought by Max Schrems, an Austrian citizen known for challenging laws that let EU citizen data flow to the US. The court case is known as Schrems II. EU citizens have a right to privacy stemming from their Charter of Fundamental Rights. The issue is whether or not the US government can secretly view the personal data of EU citizens when that data is stored in the US or handled by US companies and whether EU citizens have any remedy for it as guaranteed by their Charter. In short, US officials can compel access to this data, and there’s little EU citizens can do about it. This isn’t the first time that Schrems has thrown a monkey wrench into transatlantic data transfers. In fact, the Privacy Shield Framework that was just thrown out came about in response to Schrems’ first case, Schrems I, which challenged an earlier agreement. The implications extend well beyond the US. The decision also impacts the flow of personal data from the EU to any non-EU country ranging from China to India to a post-Brexit UK. For more on the history behind transatlantic data flows, including the impact of the Snowden revelations, take a look at this Lawfare Blog: Schrems II Offers an Opportunity-If the U.S. Wants to Take It Summary of Legal Implications The legal side of this is fascinating but also murky. Here are a few points of interest: Any EU data handled by companies from non-EU countries must have as they would have if held by a company in the EU. “the appropriate safeguards, enforceable rights and effective legal remedies” They specifically call out access by “public authorities.” A separate piece of legislation, , allows US law enforcement to compel US companies to provide access to data even when it’s stored outside of the US. This has implications for the Schrem II case since . the CLOUD Act it may not be sufficient for a US company to simply keep EU data in servers located in Europe The court allows for remedies that are contractual, organizational, and technical. Standard contractual clauses (SCCs), sometimes called “model clauses,” were not struck down, so they be sufficient to allow transatlantic data transfers. But there is a fair bit of debate about whether they will hold up going forward with Schrems arguing that they are . may effectively invalidated for US companies The problem is compelled access and broad dragnet surveillance by US authorities. US companies aren’t in a position to change these things or to refuse legitimate requests. But we’ll leave it to the lawyers to try to find loopholes and angles that work. We’ll leave it to the legislators to try to fix the laws. And we’ll leave it to the courts to better define what is or isn’t acceptable. We’ll focus on technical solutions. Three Technical Solutions That Protect Personal Data The simple answer to protecting the personal data of EU citizens is to change the trust model. Most cloud services operate on a “trust me” basis — what we call a full-trust model. Although it’s the default, it’s far from the only available trust model, and it’s far from the best choice. We’ve written extensively about SaaS trust models and defined each one in this blog: SaaS Trust Models for Security and Data Privacy To meet the EU standards for privacy in the US, a US company needs to side-step US surveillance laws, which are not limited to just gathering data that “is strictly necessary.” If a US company that is compelled to produce data produces that data in an encrypted form, then the EU citizens’ data is protected. The US authorities can still gain access to the data but will have to use other avenues and target users or cooperate with EU authorities. The solutions below all protect against overreaching surveillance, which is the basis for the Schrems II decision. 1. Zero-trust and End-to-end Encryption The most private and secure model is the zero-trust model. Companies using this model can hold customer data and provide a service without any ability to see the customer’s data (or at least the specific information that’s being protected). There are different ways to build a zero-trust system, but it’s end-to-end encryption (E2EE) that gets most of the mind share here. With E2EE, data is encrypted before it leaves a web browser or mobile device and is only decrypted on a receiving browser or mobile device. The facilitating servers don’t hold the keys and cannot decrypt the data flowing through them. Cryptography has come a long way in the past several years and importantly, using E2EE no longer means the service is “dumb” or can’t do things with the data. There are a number of techniques for operating on encrypted data on the server now. And with more powerful mobile devices and client computers, it’s much more feasible to process data on the client. Apple and Google: Examples of Encryption and Privacy An example of two different approaches is the classification of the content of photos by Google and Apple. With Google, the photos are uploaded to Google’s servers where those servers can see the contents, analyze them, and tag the photos with words related to the photos. With Apple, photos are encrypted before they’re uploaded and no Apple employee can view the photos stored in iCloud (note: some exceptions exist, like if you use Apple’s iCloud backup). Apple also classifies photos to make them searchable but does this on the client devices so Apple’s servers don’t see the photo contents. Both companies offer the same feature, but only one does so while preserving user privacy. Zero-trust Models Comply With Privacy Laws by Protecting Customer Data In a zero-trust model, it wouldn’t matter if the data held by a company is related to an EU citizen or not. For regular law enforcement, at least, this is garbage data. For the code-breakers at the NSA — well, we don’t know their capabilities, but if they have such capabilities, you can expect they’d be used sparingly to keep the secret safe. If law enforcement compelled access to the data, the company could only offer the encrypted bits. This scenario is exactly what lawmakers like Lindsay Graham are worried about when they talk about data “going dark” and when they produce legislation like . the EARN IT act But most of the “going dark” talk is hyperbole or technical misunderstanding. The data is still accessible. It just can’t be collected en masse. You need to compromise devices or target specific users with warrants to get access to the data. That’s a far cry from the convenience of large dragnets on data, but far more 4th Amendment friendly and EU privacy law friendly. 2. Trust-but-verify and Customer Held Encryption Keys So is zero-trust the only choice for companies who need to meet this new bar for handling EU citizen data? Not at all. In fact, the zero-trust model, while powerful, is not the only model that can protect data. In the business-to-business case, a can be used. We’ve talked about this before: trust-but-verify model How SaaS Companies Avoid Compelled Access With Encryption A Look at Trust, Corporate Data, Government Prying, and Practical Defenses With Customer Held Encryption Keys, a database dump of the data of a given customer will have encrypted columns that remain encrypted. A SaaS company would have to build special features to allow scraping of data to decrypt the data before returning it to law enforcement. And so far, at least in the US as far as is publicly known, law enforcement can’t compel code changes. As an extra measure, if a business is using Customer Held Encryption Keys and the customer is an EU business, then it could also make sure its keys were stored solely in the EU. They’d also be able to monitor access to their data, and revoke the access if something looks off. 3. Cryptography Based Access Control The third option to comply with Privacy Shield is to create a security model where administrators can ensure that only certain systems and people in certain locations can access the data. IronCore Lab’s GDPR pattern is expressly built to make consumer data private, keep the holders of the data from being the target of compelled access requests, minimize their risks of fines in the case of a data breach, and also to deal with related issues like the Right to Erasure (even across backups). Each user’s data is encrypted to the user, but the decryption rights are delegated back to the company. Data is encrypted as early as possible and decrypted as late as possible. Under the hood this uses something called Transform Cryptography (a flavor of Proxy Re-encryption), but we use it to classify data and then add cryptographic permissions to it that determine who can access which portions of a user’s data. For example, suppose a company holds personal information that identifies a consumer and includes their name, email, phone, and mailing address. They also hold financial information including the user’s credit card data. It’s common for the financial data to be more restricted within the company than the personal data. So the billing system and specific people in the accounting team might be granted access to all of the user data while only members of the customer support team who live in the EU are granted access to the name and address information. To everyone else, even server and database administrators, the data is useless. Now you might think that this doesn’t sound like an end-to-end encryption scheme since the server-side billing system has access to the data. You’re right. That’s not in the spirit of E2EE even though most of the data is encrypted in the client and decrypted in the client. What we have here instead is , where data is imbued with permissions describing the sets of people that can see the data. We then use to be able to change the specific people/systems that can access the data without having to touch the data itself. In this way, we support dynamic business environments and common events like a customer support representative leaving the company. Cryptography Based Access Control (CBAC) Orthogonal Access Control With these building blocks, we can build systems where data can be stored anywhere and replicated around the world, . but where administrators can ensure that only certain systems and people in certain locations can access the data As with the previous scenario, a compelled access request from law enforcement would result in a bunch of encrypted data being returned in response to the request. Conclusion The data residency implications of Schrems II are serious. Possibly standard contractual clauses are good enough, but that seems to be a matter for debate — and probably for future court cases. While all of the legal stuff has yet to fully shake out, it’s clear that businesses could, in fact, meet the standards set forth by the courts by encrypting the personal data of EU citizens in a way that keeps the data opaque to curious administrators and snooping Governments. Again, those Government requests could still be fulfilled, but they’d need to be made through a cooperating country or directly to the data owner. Encrypting data by itself isn’t sufficient. The entire trust model needs to be re-examined and re-thought. This can be effected without impacting the services provided. Schrems II is the lightning strike letting companies know that they need to move it now to keep their business insulated from the next major privacy ruling before it pulls the rug out even farther. Previously published at https://blog.ironcorelabs.com/you-dont-need-the-privacy-shield-to-hold-eu-data-775440a23e52

Flow

Apple

BUNCH

Google

Target

The Trouble with FIPS

IronHide: Better Team Encryption

Nominated for 2022 - HackerNoon Contributor of the Year - Encryption

Nominated for 2022 - HackerNoon Contributor of the Year - Data Protection

Nominated for 2022 - HackerNoon Contributor of the Year - Regulation

Too Long; Didn't Read

How to Handle EU Data Without the EU-US Privacy Shield Framework

How to Handle EU Data Without the EU-US Privacy Shield Framework

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

CCPA: What You Need to Know

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

CCPA: What You Need to Know

Windows Sticky Keys Exploit: The War Veteran That Never Dies

06/02/2018: Biggest Stories in the Cryptosphere

0-Days are on the Rise and that Means a Lot More Work for SOC Teams

Time Bombs Inside Software: 0-Day Log4Shell is Just the Tip of The Iceberg

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps