2
$\begingroup$

I'm no crypto expert but I'm trying to figure out if this is possible:

  • I'm building an application that has access to very sensitive user data.
  • I receive this data in plain text but I'm not allowed to persist it in this state.
  • When I receive data for user X, I must immediately encrypt the data using the key of user X. I can then persist the encrypted data.
  • User X needs to be able to grant the ability to decrypt their data to any other user in the system, for a defined period of time. All users in the system are trusted i.e. their identity is not in question.
  • The ability to decrypt user X's data can only be gained via user X explicitly granting permission i.e. even system admins should not be able to decrypt user X's data without permission being granted.

But, the most important part of all this is:

  • User X should be able to recover their key if they lose it. We can assume that I will have a solid multi-factor authentication flow to establish and verify the identity of user X.

So my questions are:

  1. If a user loses their key, is there a way to recover their key without having to regenerate the key? So unlike the usual password-recovery flow, I'm not looking to simply regenerate a new key, because that would effectively orphan user X's data already encrypted with the previous key. Is this possible and/or feasible?
  2. With [1] in mind, if an attacker gained full access to my database, is it possible to avoid keeping all the user keys in a central location that would expose me to this kind of attack?
  3. How would I handle providing the ability to decrypt data to an arbitrary number of users without having to re-encrypt the data for each user? i.e. I will only ever have a single encrypted version of user X's data.

I hope this makes sense. I'm happy to try to provide a better explanation.

This answer feels very close, but I'm not sure it satisfies all my requirements: https://mathoverflow.net/a/62111

Any advice and/or guidance would be most welcome.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ The approach to backups of keys is to let the user have some (backup) secret(s) that they can use to decrypt their primary keys or relevant session keys. This begs the (interesting) question: Do your users have the capability to relieably store such backup secrets? These backup secrets could be e.g. smart cards, passwords on papers or secrets stored by the user's phones or any boolean combination thereof. $\endgroup$
    – SEJPM
    Jul 25, 2018 at 14:47
  • $\begingroup$ Unfortunately I cannot rely on my users to safely keep any kind of passphrase or recovery keys. The data is intrinsically linked with their identity, so that in the event of the user losing their key, recovery would begin by the user having to re-verify their identity. $\endgroup$
    – grokling
    Jul 26, 2018 at 6:53
  • $\begingroup$ and I suppose "verifying the identity" means something like checking against a government ID or testing access to an email account here? $\endgroup$
    – SEJPM
    Jul 26, 2018 at 7:28
  • $\begingroup$ Correct. ID verification will be multi-factor, using email address, mobile phone records (from an official source) and validation of other personal attributes. $\endgroup$
    – grokling
    Jul 26, 2018 at 12:45

1 Answer 1

Reset to default
1
$\begingroup$

Delegating the decryption of encrypted data is exactly what proxy re-encryption (PRE) was designed to allow. In particular, there is a variant called time-based PRE that limits the delegation to a time period. See this paper for an example.

That doesn't really help with key recovery, though. You can encrypt the private key using a passphrase the user provides (run through a PBKDF function), but the user is still out of luck if she forgets the passphrase.

Improve this answer
$\endgroup$
0

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.