Recently I was a delegate of Security Field Day 7, where Keeper Security presented its solution. And as a security-minded guy, I have been using password managers for a long time, but I am also careful about using cloud-based password managers cause well, you store your passwords and other important secrets in that manager. What if there is a breach like recently happened to Okta and Microsoft? It means you have to be very quick to change all your passwords at all the different sites. Thus one of the big questions for me during their presentation was on storing my secret stuff on their storage (well, actually AWS via their services). 

Zero knowledge

Keeper Security is built around a very important design principle for password managers, and that is that Keeper Security must have zero knowledge of your data. That sounds a bit contradicting with a password manager that needs to save your data securely, doesn’t it?

What keeper wants to do is make sure that your data only makes sense to you. It can only leave your device after securing it in one way or the other. So how does that work? 

The image left shows the implementation of their zero knowledge principle in a model. Keeper Security has a very detailed explanation on how it works.

 I will give a brief overview of the many layers of encryption used here. So bear with me as I will walk through the different layers

Every user has an email adress and a master password. That is common to the user. The combination is used to derive a user encryption key. This is unique to the user, not the device.
That user encryption key is used to encrypt/decrypt a local client key. That local client key is stored (encrypted) in the secure enclave of the device. Each device has its own local client key and it is stored encrypted in a secure environment, protected by biometrics. Like the secure enclave in Apple Systems.

That local client key can only be encrypted and decrypted via the user encryption key or via a local device specific keypair (public for encryption, private for decryption) key when using SSO Cloud login. Here we already have two layers of encryption. The user has a derived key (of something the user knows and identifies), and that key is used for a unqiue per device client encryption key, which is secured by bimoetrics (something the user has).

And this is where it gets a bit more complicated. Each record in your password vault is encrypted with its own individual key. And that key is encrypted by that device encryption key.
This means that for viewing a single password, three different keys are needed to decrypt that single record of data. And as Keeper uses AES256 GCM encryption for their keys, a brute force still takes a very long time.

This is all for local storage, what about the cloud? Well, the hash of your user ecnryption key is used to identify you in the keeper security cloud. After a succesfull authorization of your device, and a 2FA check, the encrypted records are downloaded. That same data key (either encrypted via the user encryption key or via that keypair) is used to decrypt the different keys (record, folder or team). That individual record key can then be used to decrypt the record data (cipher text).
Then the data is again encrypted in a two-layer: the data by a record key; the record key with the local device key.

There is a lot of encryption / decryption going on in the background and that is a good thing. It might seem overwhelming and and complex at first sight, but there is a logic to it that makes sense.

  • Every individual record is encrypted with its own record key
  • For cloud storage, that encrypted record and its record key are encrypted via a data key (which can be a private/public keypair for SSO setups or the user encryption key when using master password
  • For local storage, that encrypted record and its key are encrypted with the client key which is stored securely on the local device (and never leaves it).
 It doesn’t mean it is completely unhackable, but it is a good valid design and indeed the storage in the cloud does not have any knowledge on what is actually stored; it is double-encrypted too.

 

Handy features

Besides the zero knowledge principle, Keeper Security also has some handy features that are really well thought out.

Emergency contact

During the first wave of COVID I had to work out a rather complex procedure myself, so that my partner can access the necessary passwords in case something would happen to me. Keeper has a nice feature in their family offerings, you can provide up to three emergency contacts and a specific timewindow in hours, starting from 24 hours. If one of your emergency contacts requests access, the time window is used to ask me for validation and approval. If I don’t respond to that request within 24 hours, access is granted automatically for that email address (which is logical as something happened to me). This is actually quite good, cause I don’t need to share passwords beforehand, or put data on an external offline device, etc

Enterprise features

Keeper also presented a lot of enterprise-grade features during Security Field Day. And I must say that they have been well thought out in the way you manage / operate the environment, but also how to use it, especially in today’s needs of securing API acces tokens, authorizations and other stuff. I loved their integration capabilities for devops environments

Conclusion

As I started, I have always been very reluctant on using password managers that use the cloud for storage, and cloud-based offerings. Keeper Security’s solution is very good and it is definintely worth for me to try out as succesor to my current password manager. And if you want to learn more, go ahead and watch the recording.

Share This