4

Assuming;

  • You're using HTTPS to encrypt data in transit
  • You're using server side encryption to encrypt data at rest
  • You want an ever growing amount of security for data
  • You want to store data centrally on a server
  • You want to access data from multiple different devices

While this is a great model, this naturally does end up in the situation whereby your data could still be decrypted should an unauthorised person get access to the server as the encryption key will be sat on there in one form or another.

This is one of the biggest weaknesses of server side encryption.

Then you look at client side encryption, which resolves this issue, yet brings up another issue which is around how you decouple the security from the device itself. For example when dealing with accessing via multiple devices, and/or, dealing with when your device breaks etc.

Is there a security model / design pattern that deals with these two challenges to offer maximum security?

2 Answers 2

1

The two obvious options are -

  • Client side encryption with an exportable key. The key can be backed up at creation somewhere the owner views as secure. Alternatively it can be encrypted with a user provided password and uploaded to the service - providing this additional password on client install allows additional devices to decrypt the key.
  • Client side encryption with a key derived from a passphrase. Similar to the model above with key encryption and upload except no key data needs to be stored on the remote server.

*Both of the above (assuming password encryption for the first) can be achieved with a single passphrase. An unsalted hash of the password is taken and used for the encryption passphrase. This is then hashed again before being passed to the server for authentication. The downside would be for password change all data would have to be downloaded, reencrypted and reuploaded.

1

Client side encryption with a public key does what you need.

Include a certificate carrying the public key along with the client code. Validate the certificate before trusting the key with your secret data (I recommend using certificate pinning techniques.) On the client, generate a random AES key (as cryptographically random as is possible.) Use the random AES key to encrypt the data; use the public key to encrypt the secret key. Place all of the data in a CMS (PKCS#7) structure, and ship it to the server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .