Envelope Encryption: KEK management in Auto- Login case
We are currently implementing an envelope encryption scheme in order to securely store PII data in our database. That means we will have a user- specific DEK (data encryption key), and a KEK, which will get derived from the user's password and a random user- specific salt using PBKDF2 on the frontend. The wrapped DEK (wDEK) will be stored in our database. The DEK itself will not be stored anywhere. So, until here, basically the usual envelope encryption approach.
However, one of our business requirements in the future will be to implement an Auto- Login feature for new users. That means, the user will be able to login passwordless with a simple login URL (e.g. https://www.mycompany.com/autologin/${someRandomGeneratedToken}). Our login server will validate the someRandomGeneratedToken and issue an authorization token. Thus basically, the user will be authenticated on our system.
However, in that case, the user did not enter any password. Thus, there will be no possibility to derive a KEK on the frontend.
Our current solution/idea solves this dilemma by storing the user's current KEK wrapped with a server- side secret key in our database (wKEK). After ~15days (when the auto login URL expires) we will delete the wKEK record from our database. We know, this will (temporarily) break the zero- knowledge approach.
Thus basically, when the user will want to fetch/update his PII, the sequence diagram would look the follwoing way:
- User makes a request to our server
- Our server unwraps the wKEK with the server- side secret -> KEK
- Our server unwraps the wDEK with the KEK -> DEK
- Our server uses the DEK to decrypt/encrypt the data stored in out DB
- Returning the decrypted data to the user
Does somebody know a better approach of how to make envelope encryption work with auto login?
