Managing encryption keys with database

user_9286758 0
Viewed 203

I'm stuck at the design level of implementing end-to-end encryption with Firebase Firestore.

Let's say that I store user's private key on his device, what should i do when user decides to uninstall the app and install it later, or when he loses his device?

Given that his encryption key is stored only on his device, everything gets lost, do i just create new private key and "mark" his previous data as inaccessible?

The simple solution that i can think of is storing the user's private key in the database, but that's not really the goal.

google-cloud-firestore firebase encryption
2 Answers

If the user loses their private key, you have two options:

  1. You declare their data lost
  2. You give them a way to recover their key

Both are valid options, but #2 seems to be by far the most common with Cloud-based data storage services.

If you'd store the recovery key and private in the same database, anyone with physical access to the database also has access to the keys that are needed to decrypt the data. So that's a bad practice.

The most important thing with a recovery service is that you don't store the private and recovery keys in the same place as the user's data. You could use a complete separate database (I'd recommend thinking of a different provider altogether), or any other physically separated mechanism.

user_2091030

Here is the keybase.io solution you might want to refer to.

In short,

  1. User is recommended to register multiple devices where each device has a separate pair of keys
  2. User needs an already registered device to be able to register a new device
  3. If user loses a device, he/she should be able to access the account with another registered device and delete the stolen device from the system
user_12359350
Related