Introducing Phaistos KMS; GDPR and Encryption requirements

GDPR is going to effect on May 25th. Depending on who you are and what you do, this may be wonderful news for you, or a reason for concern because it’s possible that it will affect your business in yet unforeseen ways. The GDPR changes are very significant, and will impact every EU( and UK) citizen. I highly recommend that you read the regulation; it weights at 261 pages, and it’s actually a good read.

I personally think that GDPR is going to benefit future generations(our children), and that alone is a good enough reason to welcome it, although I am concerned and bothered by the ambiguity of some articles, and by the fact that it made it possible for many “experts” to exploit the uncertainty, fear, and ignorance of organisations and people to rip them off by selling them “security” and “GDPR” services and expertise.

We have been researching GDPR for some months now, and we are confident that we understand the challenges involved, how to deal with potential problems, and what to do, but I suspect most organisations don’t really have a good grasp of the situation, and will wake up to the fact a few weeks before GDPR comes into effect, looking for ways to address it, except it may be too late by then.

One of the most important requirements for GDPR compliance is the protection of PII(personally identified information) data. To be clear, GDPR does not state that encryption is mandatory. In fact, encryption appears no more than 4 times in the regulation:

• “…implement measures to mitigate those risks, such as encryption.” (page 83)
• “…appropriate safeguards, which may include encryption” (page 121)
• “…including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data.” (page 160)
• “…unintelligible to any person who is not authorised to access it, such as encryption” (page 163)

So GDPR recommends encryption, it does not mandate it. While this may be the case, in practice you should definitely implement encryption schemes, and reasons include:

• If there is a breach, and data are is encrypted, you have no regulatory requirement to inform the data subjects affected(i.e the “users”). However, if the word gets out that you had a breach, and your data were not encrypted, expect a serious hit on your reputation, one that you may not be able to recover from.
• You have a moral obligation to protect the data trusted to you by data subjects. Even if you are not required to do so, it’s the right thing to do.

We looked for ways to accomplish that and considered using services provided by the various cloud infrastructure providers, as well as Hashicorp’s Vault. We determined the costs were relatively high, for us, given the kind of data we need to encrypt and the frequency of decryption, and also considering the latency involved for the various RPCs, we decided that we couldn’t use Google KMS, or Amazon KMS, or any other such service.

We had high hopes for Vault, but for various technical and not-so-technical reasons, we decided that we should roll our own, based on the effort and time we estimated it would take to accomplish it.

Nowadays, in general, we don’t build our own services or technologies, unless there is a really good reason to. We love OSS, and whereas in the past we ‘d almost always choose to build our own alternatives, today the opposite is true (it doesn’t help that we don’t have enough engineers to do everything we need — we are hiring btw).

So we built a simple, very easy to operate keys and secrets managements service. It took maybe a week, and we are already using it in production. Given our commitment to OSS, it was only a matter of time before we open sourced it, and that’s we did yesterday. You can read about Phaistos KMS here.

We are using a keys wrapping scheme for encryption, which is how most organizations encrypt data nowadays. It works as follows:

1. Suppose you have a dataset “users”. Whenever a new user is created, you create two keys. One is the “entity key”, and another is the “wrapping key”. That is to say, a new key is created for each distinct user.
2. You use the wrapping key to encrypt the entity key to produce the “wrapped key”.
3. You store the wrapping key on KMS (Phaistos KMS can create the wrapping key for you if you don’t want to create it yourself).
4. You encrypt all user properties (name, address, email, other sensitive information) using the entity key, and then you store the encrypted properties along with the wrapped key side by side in your database. You do NOT store the wrapping or the encryption key elsewhere. KMS owns the wrapping key from now on.

To decrypt a user’s fields:

1. You ask KMS for the wrapping key of the user.
2. You read the wrapped key of the user from the database (see (4) above). You use the wrapping key to unwrap the wrapped key to produce the entity key, that you used to encrypt the fields earlier. KMS can also be used to decrypt(unwrap) the entity key for you, if you provide it with the wrapped key.
3. You use the entity key to decrypt any fields encrypted earlier.

To update a user’s fields, you need to unwrap the entity key, as described above, and then encrypt the fields, as explained above.

One of the benefits of this scheme is that keys rotation is a simple matter of creating a new wrapping key for the entity key and updating the wrapping key on KMS, instead of decrypting all encrypted data, creating a new encryption key, and encrypting them again. This just doesn’t scale. You should read How Google Uses Encryption to Protect Your Data, where this is explained in detail.

This is the first release of Phaistos KMS. We plan to improve it, and support alternative backends for persistence in upcoming releases.