GDPR: No Data to the Rescue

Now the DGSVO/GDPR is in force for a few months — and the big bang has failed to appear for the time being. Although there are still many sides which are not available within the EU, but apart from the Cookie references for the user not much has changed, at least after the outer impression. In the first post office to GDPR I have gone into the general extent of the law and would like to go into this contribution more into the technology: Because there actually some did itself with many providers:

With the processing of personal data several (quite desirable) developments crystallize at the moment out:

• Collect a small amount of distributed data: sensitive data is stored in one place to simplify deletion/anonymization.
• Enter into order data agreements (AAV) with other parties in order to clearly communicate the responsibility and duties to the partner.
• Encrypted transmission via HTTPS: Those who believe that they can act on the market without encryption can quickly find it expensive, given the multitude of requirements and increased penalties. Because they have it in themselves: There are hefty fines due, which can even endanger the existence of a company. With solutions like Let’s Encrypt you can even secure the encryption of your own services quickly and free of charge.
• Encryption of data with public/private key methods: This form of “Privacy by Design” is particularly interesting. According to the DSGVO, encrypted data is not considered lost if the key is not also lost. This fact can then also be used in conjunction with Article 17 — the right to forget:

Sensitive data is encrypted with the user’s public key and can then be easily stored in the database:

The nice thing about this variant is that the backup processes can remain the same as before. If a user converts his right to delete, his private key is removed and he can no longer access the data. When designing an application, you have to make sure that certain data fields can now be empty even if the user has been removed.

Technically, this can be made available as a general interface:

Embedded one would place this interface in the Identity- and Access-Management:

1. An application wants to securely store sensitive data about a user. This data is sent to the API.
2. The IAM reads the key information
3. and encrypts the data with it.
4. The encrypted data set is passed to the application so that it can complete the storage process.

This pattern, also known as “Crypto Erase”, can now be discovered in many applications, e.g. Axon or in connection with a blockchain. More and more applications and frameworks will use this pattern, because it also works with distributed applications and can be easily implemented with JPA Entity Listener.

In general, this shows that data protection can also be implemented despite highly distributed applications and that comfort does not have to fall by the wayside.