14-WAKU2-MESSAGE: Security issue related to unencrypted timestamp of WakuMessage

[staheri14]

Problem

While currently, the timestamp is not part of the relay Message, it is always accessible in plaintext even when the WakuMessage is encrypted. This is because encryption only affects the payload of WakuMessage but not other fields like timestamp. As such, a relay node is able to extract the timestamp from a relayed WakuMessage. This timestamp visibility may cause security issues. For example, one can break message unlinkability by having access to the sender timestamp i.e., an attacker links messages published by the same author through the pattern of timestamps. A similar problem has been reported for Waku v1/ Whipser in this issue status-im/nim-eth#105.
@arnetheduck would be great if you could elaborate on the security issues you mentioned in https://github.com/status-im/nim-waku/pull/681/files#r677171720.

Context on the timestamp use case in Waku2

The timestamp is currently used in the store protocol to index waku messages and to enable paging for historical queries.

Acceptance Criteria

• Investigate the use of timestamps and their visibility in other systems like the Status app, Waku v1, libp2p, etc.
• Identifying security implications of exposing timestamp
• Sketching out potential remedies

Potential solutions

• Anonymizing timestamp by using a coarser resolution (use a representative value for each time interval): research directions are 1) generalization to achieve k-anonymity or 2) differential privacy to randomize timestamp

[oskarth]

Can we make this issue a bit more tight with a clear problem description, proposed solution and acceptance criteria? Right now it is a bit all over the place and a lot of text.

[arnetheduck]

Like any metadata leak, the thing to consider is what the timestamp gives us in terms of features (casual ordering?), that cannot be solved in the encrypted part of the message.

Being set by the source, a timestamp leaks information about the origin of the message, as opposed to for example receipt time which is local - assuming you're querying messages from a single history node, it's fine - what both you (and an attacker) lose in that case is the ability to make cross-server queries - I'm unsure of the value here though - basically, to establish whether you lost messages or not, you still need an in-app-protocol mechanism of detecting them and mailservers remain a best-effort solution a la UDP.

[staheri14]

Can we make this issue a bit more tight with a clear problem description, proposed solution and acceptance criteria? Right now it is a bit all over the place and a lot of text.

Absolutely, the issue is now revised! @oskarth Hope it is more clear now!

[jm-clius]

One way in which the sender-generated timestamp can be exploited is by using some form of timing/probability analysis to determine the identity of the originating peer (e.g. comparing the known latency to a peer with the time elapsed since the sender timestamp). Couldn't a possible solution be to just use a coarser timestamp resolution (say ticking only once per second, or ticking on 0.5s boundaries)? This will obscure the relationship between the latencies of specific paths and the elapsed time determined from the sender timestamp, since multiple peers will tick on the same timestamp. I understand that this may make the sender timestamp less useful, but could be decent middle way.

[staheri14]

Thanks for the comment @jm-clius!
Using a coarser timestamp resolution is one way to approach the problem, and is indeed one of the anonymization techniques for time-series data and is called generalization which yields k-anonymity. However, the issue, as you also mentioned, is about data utility. I am going to add it as one of the potential solutions (please see the updated issue description). Thanks for the suggestion!

In the meanwhile, there is a need to investigate the depth of the security issues that timestamp exposure may cause. Once that aspect gets clear, a proper solution can be picked.

[kdeme]

FYI back in Whisper / Waku v1 times I pointed out similar issue with the ttl/expiry fields there, and gave some simple example how it probably could be abused. Never made a PoC though: status-im/nim-eth#105

[staheri14]

k in Whisper / Waku v1 times I pointed out similar issue with the ttl/expiry fields there, and gave some simple example how it probably could be abused. Never made a PoC though: status-im/nim-eth#105

Thanks a lot for this comment @kdeme! for more visibility and ease of access, I am going to link this issue status-im/nim-eth#105 to the description of the current issue

[jimstir]

Issue moved here