Secret keys are useless if its confidentiality could not be assured. Ensuring the confidentiality of a secret key is the biggest nightmare in data protection.
A secret key is meant to protect (hide) data from unauthorised access. However, a secret key is worthless if it could not be generated, established, stored , used and destroyed securely.
There are many ways to keep a secret key such as storing it in a separate location from the encrypted data, generating the key on-the-fly from another input. However, One problem common to all this approach , is that the key or the secret seed that the actual key was generated from, is somewhere and is known to someone. The actual protection of any data encrypted with a key depends solely on the security of the seed and/or the key storage and who have access to them.
The actual protection of any data encrypted with a key depends solely on the security of the seed, the key storage and who have access to them.
It’s better to store data in plaintext than to store it encrypted with a compromised secret key. The worst nightmare is that an adversaries that happens to obtain the secret key could have unauthorised access to the so-called “encrypted” (protected) data for ages without your knowledge. It’s better to have prior knowledge that your data is not protected and prepare for the risks than securing it with insecure keys.
For service providers with end user application, client-side key generation and encryption is a better alternative to server-side key management. The reasons are obvious:
- Only a user is affected in case of a key compromise (assuming that each user has a unique key).
- Each user (client) key is unique, as a result, only one key could be attacked at a time.
- No client key is stored on the server, as a result, a client secret key cannot be harvested from a compromised server.
- A client is in control of its data and decides who have access to them.
Think of client-side encryption in your data security architecture where possible.
