This blog originally appeared on my Medium site on April 26, 2016. It was also shared with a number of different LinkedIn groups, and generated hundreds of comments.
PREFACE: While I believe that this is already understood, please understand that the opinions expressed in these stories / posts / blog / whatever you want to call them — are mine, and not necessarily the opinions of my current employer, future employer, former employer, or anyone else that has (or does, or will) contributed to my income or livelihood.
To get everyone up to speed (and this is a repeat of the summary I have provided before) — In October 2015, European Court of Justice invalidated the Safe Harbor agreement, requiring the European Commission to revisit the regulations between the EU and the United States. In February 2016, the EU and the US had reached an agreement (called the Privacy Shield) to address the concerns that invalidated Safe Harbor. Two months after approving the Privacy Shield, regulators in the EU have come out and stated that the agreement still did not provide adequate privacy guarantees to European Internet users. Specifically, the concerns revolve around how data is stored and used by social media and search companies. The end goal of the European regulators is to have an agreement in place that forces US based companies to treat and protect data much in the same way that it is treated by the EU countries.
In short, the Safe Harbor and Privacy Shield regulations make up a portion of the laws and controls that are central to the conversation about data sovereignty. Data sovereignty, then, is the discussion around how data that has been converted into some digital form is covered by the laws and regulations in which it is located.
So, with that out of the way…
I was fortunate enough to sit on a panel a few weeks ago on the topic of data sovereignty. The same occurred again last week, this time, in New York. Both panels — and specifically the panelists that spoke with me — were excellent. An idea was presented at the first panel, and discussed again at the second, around the sub-topic of data locality: specifically how, and more importantly — where — data is stored, and the requirements and regulations that differ depending on the country in which the data is stored.
Let me start with a non-technical narrative (one that my mother can probably understand) — a simple Master padlock, probably much like the one you had on your locker in high school:
 |
| Author’s note: never keep both lock keys in the same place… |
Not a complicated device —pretty much everyone has used a padlock at one time or another. You insert and turn the key, and the locking hasp unlocks. To relock it, simply engage the hasp back into the padlock. As long as you engaged the lock correctly and didn’t lose the key, your locker remained relatively secured (I am sure there are many high school locker tragedies, but you get my point).
When school was over for the year, you could take the lock off of your locker and could use it during the summer for your camp foot locker or the locker at the pool. The lock would still work fine, despite the change in location, so long as you had the key. Regardless of where you took the lock, the lock would function as you would expect it to — so long as you kept the key.
If you were like most, and took the lock home after the school year, only to find it in a junk box years later with your 9th grade Trapper Keeper, you would likely not remember the location of the key, rendering the lock useless. A padlock without a key is useless.
In summary:
- You can use your padlock to protect things (like your locker or camp foot locker), regardless of the location.
- The lock would work fine, regardless of the location, so long as you had the key.
- The padlock without the key — regardless of the location — is useless
Applying the narrative to the technical world, and specifically the data sovereignty discussion:
Nearly all data (the lock) has the ability to be encrypted (the key). Regardless of the location where that data is stored (high school locker or camp foot locker), so long as the data remains encrypted, the data remains protected. Put simply, if the data is encrypted correctly, and the key is kept secure, does it really matter where the data is stored? Isn’t the data useless without the encryption key?
In summary:
- You can use encryption to protect your data, regardless of the location.
- The data would be protected, regardless of the location, so long as you had (and properly protected) the encryption key.
- The data without the encryption key — regardless of the location — is useless.
One of the major components of the data sovereignty / data locality debate is WHERE data is stored. But shouldn’t the discussion be more about where the encryption keys for the data is stored and not the data itself? Properly encrypted data is practically useless without a method of decrypting the data(*).
Establishing controls for encryption key management are information security 101 best practices. So the narrative for data protection should be around how encryption keys are stored, where keys are stored, and how the data is being used once it is decrypted. Where encrypted data is being stored will make very little difference from a technical perspective.
This narrative is still evolving: there is no case law or legal challenges (that I know of) presenting and defending this perspective (yet). But there likely will be, and provided that technically minded jurists litigate the case, a reasonable (and logical) technical solution will find that data locality is irrelevant, so long as information security best practices around key management are enforced.
And I welcome further conversation about this specific concept: does it really matter where encrypted data is stored?
As for the data privacy and data use concerns at the center of the data sovereignty debate — well, we still have a long way to go on that front.
(*) Yes, I fully understand that there are some NSA / government types with massive compute that can probably break 256 bit encryption on demand, but I am not likely trying to protect my data from them. Nor *CAN* I protect my data from them…
