One of the assumptions we made for unMessage's adversary is:
6. An adversary is unable to compromise a peer's private identity key
to impersonate them in current and future conversations.
Once the key is compromised (well, the whole Double Ratchet
info), the adversary can impersonate the peer in the conversations
they had previously established, as well as sending/receiving new
ones. unMessage does provide a way to mitigate it:
- The attack mentioned in item `6` can be mitigated as unMessage
provides an authentication feature. As long as the users have
securely agreed on a secret that is not known by the adversary, the
party who the impersonator is communicating with can use it to
initiate the authentication process and detect the attack. Even
though any user can initiate the authentication at any time after a
conversation is established, it is up to them to properly handle the
secret and regularly authenticate themselves - or at least do so
under any suspicion. Even if users take such actions, unMessage is
only able to detect instead of prevent it.
The authentication feature we made for unMessage uses the
Socialist Millionaire Protocol (SMP) to compare a secret that was
agreed out-of-band (and preferably not saved to disk or at least not
in the same environment as the Double Ratchet info). That means that
only the users that own the peers can successfully authenticate to
each other, as the attacker would not know the secret. That also means
that only the ones who know the secret would initialize the
authentication. If the person controlling the peer that received the
authentication request fails to authenticate (either by providing the
wrong secret or not even advancing the process), the initiator can
assume the other peer is not being controller by the person they
expected to be.
Although this feature can detect an attacker impersonating one of the
parties, it cannot detect a MITM where the attacker:
Compromised Alice's Double Ratchet info, uses it to maintain a
conversation with Bob without raising any suspicion and modified
Alice's info to establish another conversation using keys generated
by the attacker
Compromised both parties Double Ratchet info without the need of
any modification, but just reading it
Either by 1) making a copy of one party's info and modifying the
original or 2) copying both parties' info, the attacker also
intercepts all packets, decrypts, reads and re-encrypts them,
forwarding information from one side to another.
Despite of this powerful attack, the adversary cannot initiate the
the authentication because the secret would still be unknown, but
either one of the parties can and just by forwarding the buffers would
make the authentication succeed. When deriving the key for the
authentication, unMessage uses the secret provided by the user and the
identity keys of the peers. Unfortunately the identity keys are
long-term and once either attack 1) or 2) is performed, the "right"
keys will be used to make the authentication succeed.
@rxcomm and I believe that the solution for this is using the
short-term information of the current Double Ratchet state. As soon as
the first couple of messages are exchanged between all the states
involved in this attack, they start to differ as the Diffie-Hellman
ratchets go on. That way, even when the parties provide secrets
that match, the information used to derive the authentication keys
from each side will be different, making the authentication fail.
Then the only way to make the keys match during a MITM attack would be
to constantly manipulate one or both parties' states, either
overwriting or copying the newly generated information, characterizing
a much powerful attack that possibly compromised more parts of the
system and not only unMessage's data.
One of the assumptions we made for unMessage's adversary is:
Once the key is compromised (well, the whole Double Ratchet info), the adversary can impersonate the peer in the conversations they had previously established, as well as sending/receiving new ones. unMessage does provide a way to mitigate it:
The authentication feature we made for unMessage uses the Socialist Millionaire Protocol (SMP) to compare a secret that was agreed out-of-band (and preferably not saved to disk or at least not in the same environment as the Double Ratchet info). That means that only the users that own the peers can successfully authenticate to each other, as the attacker would not know the secret. That also means that only the ones who know the secret would initialize the authentication. If the person controlling the peer that received the authentication request fails to authenticate (either by providing the wrong secret or not even advancing the process), the initiator can assume the other peer is not being controller by the person they expected to be.
Although this feature can detect an attacker impersonating one of the parties, it cannot detect a MITM where the attacker:
Compromised Alice's Double Ratchet info, uses it to maintain a conversation with Bob without raising any suspicion and modified Alice's info to establish another conversation using keys generated by the attacker
Compromised both parties Double Ratchet info without the need of any modification, but just reading it
Either by 1) making a copy of one party's info and modifying the original or 2) copying both parties' info, the attacker also intercepts all packets, decrypts, reads and re-encrypts them, forwarding information from one side to another.
Despite of this powerful attack, the adversary cannot initiate the the authentication because the secret would still be unknown, but either one of the parties can and just by forwarding the buffers would make the authentication succeed. When deriving the key for the authentication, unMessage uses the secret provided by the user and the identity keys of the peers. Unfortunately the identity keys are long-term and once either attack 1) or 2) is performed, the "right" keys will be used to make the authentication succeed.
@rxcomm and I believe that the solution for this is using the short-term information of the current Double Ratchet state. As soon as the first couple of messages are exchanged between all the states involved in this attack, they start to differ as the Diffie-Hellman ratchets go on. That way, even when the parties provide secrets that match, the information used to derive the authentication keys from each side will be different, making the authentication fail.
Then the only way to make the keys match during a MITM attack would be to constantly manipulate one or both parties' states, either overwriting or copying the newly generated information, characterizing a much powerful attack that possibly compromised more parts of the system and not only unMessage's data.