Bug #17156

CPU-induced latency Covert Channel Countermeasures Testing

Added by HulaHoop about 1 month ago.

Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:
Affected tool:


Hi Whonix dev here. We are currently working on tackling multiple side and covert channels of TCP which was inspired by your previous research and solution for TCP Timestamps. I would appreciate your help in thinking about and testing the suggested mitigation for an attack related to CPU load effect on packet timing.

A Tor user posted an attack he discovered on their mailing list that it is possible to influence packet latency (ping in this case) by manipulating CPU load thanks to CPU powersaving features (C-states). An attacker would easily use this as a covert channel to deanonymize users.

We discussed solutions with him and the most feasible I thought of was adding random delays to packets to destroy any covert messaging an adversary might attempt (as opposed to running a background process that keeps processor usage constant - which would kill battery life and overheat the computer)

He wrote some code at the time where unfortunately 1) The package doesn't build 2) pulls dependencies from unsecure sources outside Debian then he stopped communicating.

Fast forward three years later, I am revisiting this with a fresh perspective and manage to find a utility on Linux and that's packaged in Debian that readily induces package delays on a chosen interface. tc-netem part of the iproute2 suite does what we need using Kernel features.

Cyrus a PhD student has kindly given us feedback on the suggested command and we would like to test the efficacy of these defenses in the real world. [1]

Offtopic: He is also working on a userspace solution for TCP ISN privacy leaks which we will share when ready.


Also available in: Atom PDF