search

srlabs / blue-merle

The blue-merle package enhances anonymity and reduces forensic traceability of the GL-E750 Mudi 4G mobile wi-fi router
BSD 3-Clause "New" or "Revised" License
186 stars 29 forks source link

Suggestion: Additional Seed in deterministic mode #2

Closed olastor closed 1 year ago

olastor commented 2 years ago

In the spec it says:

3.1.2.1 Link between IMEI and IMSI in deterministic mode In deterministic mode, the IMEI is statically derived from the IMSI. By checking the relationship between IMSI and IMEI, an observer can identify that a blue merle IMEI changer is in use.

I think by adding a secret / salt, that the user provides additionally, e.g. by a parameter --deterministic-salt, which is also used to seed the random generator ("salt + imsi"), the relationship between IMSI and IMEI could not be traced back anymore, right? Not sure if that would practically improve it (since there is already a random mode), though. Just as a suggestion / feedback.

Linuzifer commented 1 year ago

Hey @olastor, thanks for the suggestion. We gave it some thought:

One of the design goals was to not store any unique identifiers in the file system, as blue merle is mainly about eliminating unique identifiers. Adding a static seed to deterministic mode would, as you correctly explain, result in a random IMEI plus a static unique identifier in the filesystem. This salt could later serve as post-hoc evidence that a specific mudi was used with a specific SIM even after the SIM was ditched.

This is why we decided not to offer implement that mode.

olastor commented 1 year ago

@Linuzifer I see, thank you for the explanation.