3.11.4 Security Limitations

While our concept of identity provides strong security guarantees, there are still attacks it won’t be able to prevent. An attacker who is able to register a new device in the system on behalf of a non-consenting user, whether by stealing the user’s credentials or compelling the server, will be able to read data that is E2E-encrypted to the targeted user after the compromise (but not before, as explained above), as it will be able to add a new compromised PUK to the user’s chain, which might be used by other users to encrypt messages intended for the recipient before the recipient has had a chance to come online to review and revoke the new device. This attack can be prevented if the sending user compares fingerprints out-of-band with the potentially compromised recipient(s) before encrypting for the new PUKs, or detected by comparing fingerprints (possibly implicitly through the ZTT) after the fact. When one of a user’s devices is revoked, the per-user public encryption keys for that user become stale and should be rotated as soon as possible. When another of the user’s devices comes back online, they will pick new encryption key pairs, publish the public keys in a new sigchain link, and encrypt the secret portions for all the user’s devices that are still active. If one of the user’s devices is revoking another one, key rotation can happen immediately. However, in case of self-revocation or revocation from the web or by an account administrator, if none of the other user’s devices are online, this rotation might be delayed. A delay can also happen if escrow is disabled, or the user is moved between accounts (with different escrow administrators) while being offline. Any data encrypted to this user during this period would be using an encryption key known to a revoked device (or to old escrow administrators’ devices), and we rely on the server to enforce that these devices can no longer access user data. An attacker who both compromised a revoked (or escrow administrator’s) device and had read access to the server might thus be able to decrypt this data. Although the attack window seems limited and hard to exploit in practice, this is a limitation of the current design. Similarly, when a key is revoked and rotated out, we do not re-encrypt old ciphertexts for the new key, and rely on the server for access control to the ciphertexts. We stress that, while escrow enables necessary enterprise features such as account recovery and data retention, EAs’ devices have keys that allow them to decrypt all data in their account: as such, this privilege should be restricted to a few security conscious users to minimize the potential for compromise.