Vulnerability found: Key Replacement on Source Submission

[lumaier]

Summary: There is an attack scenario, where an active network adversary can alter messages to retrieve the plaintext of the source's submission.

Scenario: Before source submits an initial message, the server sends $JC{PK}$ and ${}^iJE{PK}$ including their signatures to the source. If the active network adversary removes $JC{PK}$ and instead sends ${}^iJE{PK}$ a second time (alongside its signature), the verification of the signature succeeds and the source outputs $message\_gdh = DH(JC{PK}, ME{SK}) = DH({}^iJE{PK}, ME{SK}) = k$. That is, it leaks the symmetric encryption key which can be used by the network adversary to decrypt the submission ciphertext $c$.

Mitigation: The source needs to check that the keys $JC{PK}$ and ${}^iJE{PK}$ are distinct. This could potentially be implemented by incorporating key types into the signature.

[lsd-cat]

Thanks you! This is such an important and clever find :)

As you suggest, I think we should incorporate key purpose/type every time we sign something. We cannot expect to manually prevent and check in code for this kind of edge cases (such as, checking that the two keys are explicitly distinct) because we would surely incur in more overlooked and possibly security relevant edge cases. Plus, if we think of writing a more formal specification, and imaging the possible of multiple implementations by that, we should force coding to be as less error-prone as possible.

We should probably add key types in the PoC as well, to keep the code up to date and test with serialization/formatting for keys at this point (currently a signed public key is a raw structure of a signature of the bytes public key only). So this also open the question whether we should move to a more structured format, and if it might be worth the network and storage overhead.

[lumaier]

The same issue arises for journalist responses. If a source chooses $S{PK} = $SC{PK}$, the key $k$ used by the journalist to encrypt its response will be equal to $message\_gdh$ included in the journalist's response.

Since this is under the control of the source, this is not really a security issue but an edge case to consider in the implementation (maybe you already do).