1

Issue: I provide a small web portal for customers with partial personal data like name, address etc. which is stored in the database in plain text. Now I need a safe concept to encrypt the personal data in the database. The encryption is no problem, but how to handle the decryption of the data? 1.) server-side: problem is how to avoid man in the middle (Key exchange, always at log in??) 2.) client side: how to implement and there is now opportunity of long-term saving a key on the client side ... Thanks for responds. Greets

Improve this question
7
  • 1
    Why do you need to store this data in an encrypted form in the database? That is a fairly unusual approach. What kind of threats do you want to defend against by using encryption at rest?
    – amon
    Jan 21, 2019 at 9:19
  • 1
    The near universal generic solution is to turn on your DB's encryption features for the whole database. Obviously any encryption that you can decode has the same flaw. If your retrieval process is compromised then the data can be read.
    – Ewan
    Jan 21, 2019 at 9:35
  • Thanks for the fast replies. 1) Because of the new protection of personal data law in the EU. If the server get hacked, the attacker gets all the personal data. If it is encrypted, there is no use for it. 2) thats correct. perfect scenario would be that the server side has no opportunity to decode the encrypted data. It can be only done at client side which guarantees me immunity of getting fined. Problem is how to handle the whole key situation? when and where are the private keys of the user generated and stored? Do I have to generate keys for every log in session?
    – Daywalker123
    Jan 21, 2019 at 10:08
  • If your DB files are encrypted then the info in encrypted. Your challenge with GDPR is preventing non authorised use of the data by yourself
    – Ewan
    Jan 21, 2019 at 10:19
  • @Daywalker123: For encrypted storage scenarios (where the unencrypted data should only be available to the person/entity that stored the data), you should look at symmetric encryption schemes (which use only a single key, rather than a public/private key combo).
    – Bart van Ingen Schenau
    Jan 21, 2019 at 10:48

1 Answer 1

Reset to default
1

Having a database store encrypted contents and end-to-end encryption are quite frequently NOT feasible approaches. The problem is who has access to the plaintext contents. E.g. for a web app:

  1. The server provides the encrypted contents and JavaScript software to perform the decryption and access the contents.
  2. The user enters their password, from which the (symmetric) encryption key is derived.
  3. The user can access and modify the plaintext data.
  4. If changes were made, the data is encrypted again and sent back to the server.

There are two huge problems with this:

  • The password or encryption key must not be known to the server. If the service requires a password then the same password must not be used to derive the encryption key. So we need another login mechanism or two passwords. Either way, this complicates the system. Compare the MEGA file hosting service and e.g. 1Password.

  • The decryption software on the client has access to the plaintext content. But who provides this software? For a web site, anyone who has access to the server could insert a backdoor. Some criticism of end-to-end encryption in WhatsApp also points out that the app update mechanism could be used to backdoor the encryption in the future, even if a current version is not backdoored.

A third problem is that this requires any processing to happen on the client, since the server does not have access to plaintext. This is not feasible for many kinds of processing, such as databases that model relations between records, or special processing that is simply not feasible on client devices (such as video transcoding).

A fourth problem is that encryption of contents has limited value when the metadata are still stored in plaintext. E.g. while WhatsApp encrypts message contents, your online presence (online/last seen) may leak to the whole world. So simply applying some encryption here and there does not result in a privacy-respecting service.

The real problem that motivates your question is GDPR compliance. The GDPR is not about mandating technical features such as encrypted storage. Instead, the GDPR requires you to have some sensible process that protects the personal data of data subjects in everything that you do. The result of this process will typically be appropriate organizational and technical measures. Encryption may be one appropriate measure (transport encryption is effectively a must), but superficial encryption at rest is not helpful. Organizational measures may be policies on who can access the data, physical security measures to defend your servers against unauthorized access, contracts with your data processors, and so on. Code reviews and running vulnerability checkers can also be reasonable measures.

So instead of jumping to a conclusion “OMG I have to encrypt ALL the data” it may be better to take a step back and go through a GDPR compliance checklist and possibly prepare a data privacy impact assessment. Roughly:

  • For what purposes will I be processing personal data?
  • Which kinds of personal data will I have to collect for this processing?
  • Under what legal basis will this data be processed? E.g. consent, legitimate interest, necessity for some contract, other legal obligations.
  • If legitimate interest: do the interests of the data subject outweigh my interests for processing the data?
  • What organizational and technical measures are appropriate to protect this data? Some measures like pseudonmymization can also change the balance of a legitimate interest analysis!
  • Am I providing transparent information about this processing to data subjects and am I informing them of their rights?
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.