- •Teams Table of Contents
- •Signature Chain V2
- •Per-User Keys
- •Naming and Signature Chain Details
- •Team Crypto Details
- •Cascading Lazy Key Rotation
- •Loading Teams on Keybase Clients
- •Downgrade Leases
- •Seitan Tokens V2
Our public keys
Users on Keybase have one or more device keys, whose public halves are advertised in the user's signature chain, and whose private halves stay local to the device that generated them. Users can also have paper keys, which act as device keys for the purposes of recovery from lost devices.
With the rollout of teams, we introduce a new type of key: the Per-User Key or PUK. Conceptually, the secret half of the per-user key is encrypted for all of a user's active device and paper keys. The public half is advertised in the user's signature chain. When a user adds a new device, the secret-half of the PUK is simply encrypted for the new device. When the user revokes a device, a new PUK is generated, and all remaining devices get the new secret half.
Users start at PUK generation 1. Every time they revoke a device, they increment their version number and roll their PUK. At generation _i_:
- A user generates a 32-byte random seed _s_.
- Computes _e_ = HMAC-SHA512(_s_,
"Keybase-Derived-User-NaCl-EdDSA-1") and uses this value as the secret key for an EdDSA signing key. Then computes the public half, yielding keypair (E,e)
- Computes _d_ = HMAC-SHA512(_s_,
"Keybase-Dervived-User-NaCl-DH-1") and uses this value as a secret key for a Curve25519 DH encryption key. Then computes the public half, yielding keypair (D,d)
- Computes _c_ = HMAC-SHA512(_s_,
"Keybase-Derived-User-NaCl-SecretBox-1") and uses this value as symmetric secret key.
This process is repeated at every generation _i_. At any given generation, the public keys _E_ and _D_ are signed into the user's public sigchain. Whenever a new device is added, _B_ is encrypted for the new device's device key. This is an instantaneous operation and significantly improves keying performance over previous designs we've consdired and implemented. These NaCl boxes are written to the server and stored in the main DB. The current _s_ should have a box for every active device.
On device revoke, the revoking device makes a new PUK, encrypts for the private key for all remaining devices, and writes the new PUK to the sigchain along with the statement revoking the old device. Also, whenever the key rolls over, the previous seed _s_i is encrypted with _c__i_+1 via NaCl's SecretBox symmetric encryption, with a random 24-byte nonce. See newPerUserKeyPrev and openPerUsrKeyPrev for an implementation of encryption and decryption, respectively.
The relevant sections are:
As with any signing key, a reverse signature is computed with the new signing key over the entire JSON body, but with the
reverse signature set to empty. This proves that the user knows the private key corresponding to the adverised
One of these links appears every PUK generation, or roughly, whenever a user revokes a device.
Teams the user is a member of will need to rotate their shared symmetric keys, but this can happen lazily (before the next write) and off the critical path (see CLKR).
Users just joining Keybase get a PUK when then provision their first device. Some users were active before PUKs were rolled out, and their clients opportunistically upgrade to include a PUK upon software upgrade.
Note, this change introduces a new state a user can be in: they are signed up for keybase, they have device keys, but they don't have a PUK as described above. New CLI users won't get here, but legacy users and new Web users will. This makes some flows (like inviting users into teams) more complicated.