Considerations before using keybase.io

Considerations before using keybase.io

TL;DR: We don't recommend storing any other than keybase-generated secret keys in keybase local keychain.

Keybase.io is a service that according to their website "maps your identity to your public keys, and vice versa.". It is also doing other optional things such as an encrypted filesystem and synchronized key management. And key management is something we would like to discuss in this article.

The problem

Keybase.io features a Local Key Security (LKS) as follows:

Whenever a user stores a secret key on a device, it would be nice if she could encrypt that key with her passphrase, and if she changed her passphrase on any one of her machines, it would be reflected on the others.

We've developed a simple server-aided protocol to do so, in which a server-side mask is updated during a password change, so that encrypted device keys on offline clients will be decryptable with the new password. The server supplies this mask during decryption, but device keys are never exposed to the server, even in encrypted form.

One vulnerability of the password change scheme, is that it's possible to decrypt secret keys using an old password. If a user's password was compromised, and an attacker was also able to obtain the user's server-side mask, then that attacker would be able to decrypt the user's local keys even after the user did a password change.

The above texts are quoted from https://keybase.io/docs/crypto/local-key-security.

The security issue

To be able to really decrypt user's local keychain you would need to have:

  • knowledge of any old user's password
  • copy of unencrypted local keychain from any of the user's devices
  • knowledge of the server-sent mask corresponding to the old password (if you are the Keybase.io server everyone sends you these)

Practical demonstration

Say you have followed these steps:

  • Setup your keybase local keychain on a device with your keybase password `p1`. The device-local keychain is encrypted symmetrically with a randomly generated key `k` for which `s1` is computed as `s1 = k XOR scrypt(p1)`.
  • The mask `s1` is then sent to the keybase.io server
  • Now consider your password `p1` has been compromised.
  • You change your keybase password do `p2`.
  • New mask `s2` is computed so that `s2 = k XOR scrypt(p2)` and sent to the server again.
    - Anyone, who knows the compromised password `p1` AND the mask `s1` can compute `k = s1 XOR scrypt(p1)`, thus having all information necessary to unlock the keychain.
  • This method can be used for any old password. The local keychain does not change, so a copy of encrypted keychain from any time period (before the change of the password or after it) works.

"Hope there is!"

But not implemented yet.

To prevent this, when decrypting keys, a device should notice that the current passphrase is newer than the one its keys were originally encrypted with. In that case it should generate an entirely new encryption key

As explained in the last section of https://keybase.io/docs/crypto/local-key-security.

Practical implications

Changing password doesn't help.
The local keychain is only as secure as the weakest password you have ever used to protect it.

Publishing your public PGP key

If you want to publish your PGP public key, skip import to keychain:

keybase pgp select --no-import

This will only create a proof that you own the key and send the proof to server.

For the paranoid: The keychain is stored in a file `secretkeys.<your-keybase-nick>.mpack` somewhere in your Keybase installation path. It should stay untouched after uploading public key with the `--no-import` flag.

Author

https://keybase.io/dominikzajicek

About the author

Citadelo
Citadelo
Citadelo is a firm of ethical hackers on your side. We think like hackers, but we don't abuse it. On the contrary, our main goal is to reveal vulnerabilities without causing damage. We have been conducting simulated attacks for our clients since 2006
Show more from author

Related blogs