Dev/Advanced Deanonymization Attacks
Donate
Notes on Advanced Deanonymization Attacks.
Covert Channels[edit]
This page is a brain-dump of all known covert channels and mitigation ideas. A refined version for users will be written later when countermeasures are deployed.
See also: Advanced Deanonymization Attacks
Ticket: Covert Channels Meta Ticket
Topics[edit]
Some covert channels can be eliminated outright, while others need to be sufficiently degraded. The good news is that it is possible to defend against all of them, though not without cost.
All problems are interconnected: keystroke dynamics, CPU-induced network latency, TCP ISN CPU temperature-induced timer skew, DRAMA cross-VM keystroke monitoring, and CPU-cache cryptographic side channels.
Covert channels are part of the TEMPEST category of attacks. Cryptographers have dealt with them for a long time, but they pose serious challenges for systems aiming to isolate untrusted, malicious processes. They can be classified as either snooping on activity outside a VM or secretly communicating with the outside world.
Keystroke Fingerprinting[edit]
An excellent paper on covert channels in general: USENIX Paper
CPU stress as a solution for keystroke fingerprinting? Not effective.
Question: How to delay keystrokes? StackOverflow answer: Funnel all system input events through a local network interface and inject random latency. This must be done on the host to apply system-wide.
uinput is the kernel input device API, but it requires C expertise to write a program for direct implementation.
usbip? It is in the mainline kernel but not a solution for PCI input devices, which most PCs use.
Network latency mitigation: Use the iperf stress tool or Ethan's netfilter_queue solution.
Alternatives:
- Linux share keyboard over network
- Share keyboard over network as a separate device
- NetEvent - Share devices over the network
NetEvent cobbles together netcat host/client on a loopback interface. It runs as a service with the client as localhost. Applying netfilter_queue on the loopback interface introduces random delays.
- Pros: Kernel-based solution, display server agnostic (it captures all events using the uinput interface).
New research results on obfuscation: No working tool yet. Contact researchers to inquire if they can develop one.
TCP ISN[edit]
Blocking TCP ISN at the firewall? Rewriting TCP ISN?
- Not possible and necessary for security. TCP ISN is a fundamental part of all modern operating systems.
References:
- 23C3 Presentation
- 23C3 Event
- 22C3 Event
- Hot or Not: Revealing Hidden Services by Their Clock Skew
- EuroBSDCon Presentation
- Light Blue Touchpaper Analysis
23C3 Slide 30:
- Running the CPU at full load is an inefficient mitigation method.
- Different tasks have varying temperature effects.
- Full CPU stress is required for TCP ISN mitigation to maintain constant CPU temperature and foil skew patterns in timers/crystal clocks.
Mitigation must be applied on the host to remain out of reach of malicious code inside the VM.
CPU Activity-Induced Latency[edit]
Mitigation: Quality of Service (QoS) solution by Ethan White.
Originally proposed in 23C3 slides and later realized.
Status: Stalled.
DRAM Addressing[edit]
A severe risk: A process inside an anonymous VM can sniff keystrokes from other VMs, leading to data leaks. Scenario: JavaScript running in a browser can exploit this.
DRAMA: Exploiting DRAM Addressing for Cross-CPU Attacks
Test Proof-of-Concept (PoC):
Mitigation: Memory stress
- The stress-m2 method, when applied in parallel (i.e., the attacker's core is under stress), makes measurements impossible.
- No false positives occurred in tests, but only 9 events were correctly detected.
- The attack is susceptible to noise, especially if the attacker only has a fraction of CPU time.
NUMA combined with CPU pinning:
- Described as a valid mitigation, but NUMA environments are mostly available for server systems.
Mitigation must be applied on the host to stay out of reach of malicious code inside the VM.
In this attack, the spy and the victim can run on separate CPUs and do not share memory, i.e., there is no access to shared libraries and no page deduplication between VMs.
Cryptographic Side Channels[edit]
Mitigation:
- vCPU pinning to physical CPUs ensures no cross-cache attacks on cryptographic processes.
- This also makes other attacks significantly harder.
See also[edit]
The most watertight privacy operating system in the world.
At
Whonix we value freedom and trust, supporting Open Source and Freedom Software
2012-
2025 ENCRYPTED SUPPORT LLC
We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!