Opened 2 years ago

Last modified 2 years ago

#1849 new enhancement

Document why signature in SSU SessionCreated msg is encrypted

Reported by: zzz Owned by:
Priority: minor Milestone: eventually
Component: www/i2p Version: 0.9.26
Keywords: Cc:
Parent Tickets:

Description

Add to the SSU overview and/or spec.

Also research in java code, mtn commits, and 10-year-old meeting logs, status notes, and emails for additional info.

<EinMByte> zzz: Ah, I found out why we need to encrypt the signature
<EinMByte> or at least why we do it
<EinMByte> zzz: An attacker could substitute the signature with their own signature, and hence claim to have sent the message
<EinMByte> zzz: But it does not seems to be applicable to I2P, because both parties know each others RI and hence public keys
EinMByte> zzz: It all comes down to whether or not it is feasible for an attacker to intercept the DatabaseStoreMessage?, and substitute it with their own
<EinMByte> But maybe it's a good idea to keep the encryption there anyway, just in case that is probably
<EinMByte> For sure, there MUST be a note on there
<EinMByte> s/there/that

Subtickets (add)

Change History (2)

comment:1 Changed 2 years ago by EinMByte

More information regarding this attack, and also why it is a good idea to sign both X and Y for both parties can be found in Diffie, W.; van Oorschot P. C.; Wiener M. J., Authentication and Authenticated Key Exchanges. (section 5.1).

To elaborate on the above: it seems like the attack is mainly applicable when certificates (issued by a trusted third party) are used to exchange public keys.
In the I2P context, a peer always attempts to connect to a particular router hash (a router is its RI), so it is not possible to substitute the certificate at all. Importantly, this identity information is included in the exchanged signatures.

I think this consideration also rules out the possibility of unknown key-share attacks to which the protocol might otherwise be vulnerable. The appropriate reference here is Blake-Wilson, S.: Menzes, A., Unknown Key-Share Attacks on the Station-to-Station (STS) Protocol.
For STS-ENC (close to our transport protocols), two attacks are described there
1) Public key substitution: the attacker is able to register the public key of one of both parties as their own. This is not possible in the I2P context.
2) An attack based on the assumption that an attacker is able to create an (invalid) RI such that the signature by Alice is also valid for that RI. Such an attack on the ElGamal? signature system (with freely chosen and unchecked parameters) is discussed in that paper, but it is not very practical (and doesn't apply at all to I2P).

So it looks like we don't need the encryption as long as the identity information is being included in the signatures. If this was not the case, consider the following attack

Alice                Mallory                    Bob
==================================================
X, RH(A) ----------> X, RH(M) ------------------->
<------------------------------------ Y, S_B(X, Y)
S_A(X, Y)----------> S_M(X, Y) ------------------>

Bob shares a key with Alice, but in fact thinks this key is shared with Mallory (unknown key-share attack against the responder).
Even using this weak version of the protocol, you cannot trick the initiator in the same way, because Alice knows that she wants to talk to Bob, and will only accept his signature.

Last edited 2 years ago by EinMByte (previous) (diff)

comment:2 Changed 2 years ago by EinMByte

I'd like to make a correction to the above post: only the initiator (Alice) already knows the RI of the other party (Bob), so it is required after all that Alice encrypts her signature.
It is not true (as I mistakenly assumed) that Bob knows Alice's router hash.

So the attack described above would work in the I2P context (if we didn't encrypt signatures), since Mallory can just recreate the signature with his own router hash included (in the scenario of the above post it isn't included at all).
By making Alice encrypt her signature such an attack cannot work:

Alice                Mallory                    Bob
==================================================
X, RH(A) ----------> X, RH(M) ------------------->
<------------------------------------ Y, S_B(X, Y)
E_K(S_A(X, Y))-----> E_K(S_M(X, Y)), K?? -------->
                     ^ Mallory cannot perform this operation.
Note: See TracTickets for help on using tickets.