I have a Progressive Web Application (PWA) with a lot of users, each user creates a public-private keypair and wants to use that across devices simply by logging in using some form of auth, for example, Google SSO, etc. If there was some sort of secure cloud key vault (from one of the big companies like the ones that are identity providers) that allows a user to store or encrypt/decrypt a private key using that Google SSO auth - the device A could store and device B could fetch the keypair from there, or encrypt the pair and store it on my servers.

I wouldn't have any way to access that keypair in principle - and that's what I want, only a user and a vault manager should have access to that. I couldn't find a readily available answer on whether Amazon KMS admin or Azure Key Vault admin can encrypt/decrypt data using user's keys, but that's probably the case - and that is what I absolutely don't want.

I'm aware of the solution some apps like WhatsApp and Telegram do - they don't use any cloud and just use/transfer the keys by scanning QR codes - but it's a hassle for the user, and simple Google login is easier - and I'm trusting Google anyway. I don't want any additional UI for the user, you logged in on the other device - you can instantly use your keys there - the UX should be as simple as possible.

P.S. I'm also aware one can do this by having a user remember a master password, and encrypt the sensitive data using that password and upload the encrypted blob to my server, however this is worse than just clicking Sign-in with Google/Facebook/etc. and we don't want that either.

  • How does the vault know which device it should send the keypair to, and which one isn't allowed? Google SSO auth, you say? why not have the user log into your app with their google account, and generate a new keypair for each device?
    – user253751
    Apr 26 at 17:36
  • Yes, the vault knows it should only send the keypair for the device that presents the correct token that is issued only by a well-known identity provider - i.e. user logged in on this device. There must be only one keypair - that's a requirement. It can be some other sensitive data though, like a symmetric key for decrypting some data that should be synced between devices. Apr 26 at 17:54
  • I think Google's "secure cloud vault" is called Google Drive by the way :)
    – user253751
    Apr 26 at 18:13
  • Some user-controlled cloud storage is an acceptable solution probably, however I don't know if it's possible - a small storage that is accessible from the client only (mobile, browser) through some API (hidden from the user, no UI) and some IdP login? Apr 27 at 13:38

1 Answer 1


If your goal is to convince the most skeptical of consumers, your server being able to see the key material at all (store it as securely as you want) wont be acceptable. Even just to ensure there is no misuse of keys in the system, if it can be exported unencrypted, it can be used by an attacker.

In these cases the best bet is to encrypt/decrypt key material on device and only stored in the wrapped form on your servers. The most user friendly way would be to HKDF or something along those lines using the user's password. Nothing new to remember and presumably they've logged in before getting the key blob. This is roughly how services such as protonmail work.

  • Sure, the private key must not leave the device unencrypted and probably should only ever exist unencrypted for the short duration needed to sign a message. This is of course can be accomplished by user's master password, like SSH protected key files - user has to enter the passowrd every time. However, I don't want a master password. Can it be done just using some IdP stuff? Theoretically it is sound - user proves his identity to the IdP on both devices and gets access e.g. for the HSM that encrypts/decrypts what a user wants. And I pay the service cost to the vault provider. Apr 26 at 19:02
  • "must not leave the device unencrypted" - I mean TLS to vault HSM server is probably acceptable since it's not me but a big trustworthy player? Apr 26 at 19:12
  • CloudHSMs have a max key count per cluster. A two second google said 3300 on AWS. So every user certainly can't have their own key in the HSM (unless this is a really narrow deployment or probably really expensive). So I'll assume you mean a singular HSM controlled key. That would allow anyone with IdP to submit any encrypted key blob and have it decrypted. Maybe there's some controls to make sure that key blob belongs to them but still feels like playing with fire.
    – foreverska
    Apr 26 at 19:23
  • Plus if it's decrypted cloud side, that means somewhere it has to exist in the clear on the server. Probably pretty narrow threat profile handled correctly but it does exist.
    – foreverska
    Apr 26 at 19:27
  • "3300 on AWS" - I didn't know that, thanks. Yes, with that I can't see how it could work, each user must be completely independent from the others, and me. "has to exist in the clear on the server" - on the decryption provider server, yes, before sending back. Apr 26 at 20:11

You must log in to answer this question.

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