3.4.1 Per-User Keys
One application of the trust graph is to facilitate per-user keys (PUKs); a set of keys shared between all of a user’s devices, rotated on device addition or revocation.
In each DeviceAdd or DeviceRevoke operation, devices generate a new PUK seed. The PUK seed is encrypted for each unrevoked device’s device key; devices implicitly trust all older devices (otherwise, they would revoke them). Each seed is associated with a number called a PUK generation, which starts at 1 and increments every time the seed rotates. All devices within an approval class share the same set of known PUK seeds.
From each PUK seed, devices generate subseeds, symmetric subkeys, and asymmetric subkeys for various applications such as email and voicemail.
Symmetric PUKs facilitate syncing encrypted data between a user’s devices. Devices use the latest per-user key to encrypt all content, but previous per-user keys are still useful for decrypting older data. In the above example, if it is provisioned, it doesn’t yet have access to older PUKs; only the one it just created. But if an older device performs a BatchApprove that includes f, it will also encrypt all the PUK seeds it knows about for the devices it’s approving, which means f can now decrypt data encrypted with keys created before f was introduced.
Asymmetric encryption PUKs can be used to encrypt data for other users. If Alice encrypts a piece of content for Bob using his most recent asymmetric PUK, Bob can read the content on all devices added before the content was encrypted, as well as all the devices added afterwards, as long as those devices have been approved by an earlier one. The public keys corresponding to the asymmetric keys derived from the PUK seed are published in the user’s sighchain (Section 3.5.3).
To generate a set of PUKs, devices:
Generate a new 32-byte secret seed.
Use HKDF on the seed to generate different 32-byte keys: (a) private X25519, context “Zoombase-2-ClientOnly-KDF-PerUserX25519” (b) email seed, context “Zoombase-2-ClientOnly-KDF-PerUserEmailSeed" "Zoombase-2-ClientOnly-KDF-PerUserEmailX25519” (c) voicemail seed, context “Zoombase-2-ClientOnly-KDF-PerUserVoicemailSeed" "Zoombase-2-ClientOnly-KDF-PerUserVoicemailX25519” (d) symmetric, context “Zoombase-2-ClientOnly-KDF-PerUserSymmetricKey”
See Appendix B for a deeper analysis of multi-device configurations and the guarantees we can achieve given these rules. In summary, a newly-added device will immediately be able to send and receive new encrypted content that is accessible from all devices. Approving a device will give that device access to past encrypted content. If a device is revoked, that device is unable to decrypt any content encrypted after the revocation.
Note that if a device is self-revoked, the necessary key rotation might not happen immediately if there are no other suitable devices online to perform it. Before the key rotation is completed, we rely on the server to enforce that the revoked device does not access further user data, including ciphertexts sent both before and after the revocation, by no longer accepting the per-device authentication tokens and signatures using the keys the device owns. This is not a cryptographic guarantee and relies on the server’s honesty, and also does not cover any content already in the device’s memory before revocation.