3.11.2 MitM Between Different Users

Another class of attacks involves an MitM between the sender and recipient of an encrypted communication. An insider might lie to the sender about the recipient’s sigchain and PUKs or add a malicious device to the recipient’s sigchain, causing the sender to encrypt for a key controlled by the attacker. These attacks can be prevented or detected by checking fingerprints, and can in many cases be detected after-the-fact with minimal user burden by leveraging the ZTT. Consider an adversary compromising one of the recipient’s devices or backup keys, thus obtaining their secrets. With access to the device, an attacker could obtain all the recipient’s data, both locally cached and stored by the server (at least until their session expires). If the user discovers the compromise, they could revoke this device and rotate their keys, preventing further data leakage. However, if the attacker also compromises (even at a later point) the Zoom server infrastructure, they might attempt a more subtle attack: when a sender requests this recipient’s sigchain, the server could provide a legitimate but stale version of this chain, i.e., one that does not include the device revocation and the subsequent rotation. This attack can be prevented by comparing fingerprints. However, detecting this compromise using fingerprints after the fact is not that straightforward: the sender and recipient would have to ensure that they agree on their views of the recipient’s sigchain at the time the message was encrypted and sent, rather than at the time of the fingerprint comparison. Assuming all clients have synchronized clocks, one way to achieve this would be to have each sigchain link include a timestamp. Each client would remember the last time they updated their view of any sigchain and refuse to accept new links for that sigchain that have an earlier timestamp. In order to be tolerant to time misconfigurations, we currently do not enforce these properties, but we are considering them for future updates. Eventually, the ZTT might also ensure, under similar time synchronization assumptions, that everyone’s view of all sigchains is not only consistent, but also relatively up-to-date, i.e. that any attempt to withhold updates beyond some reasonable tolerance bound is detected. This will ensure that the server is not able to trick senders into encrypting for out-of-date keys unnoticed.