[Whonix-devel] [qubes-devel] Re: Exposing AnonVM Users with Dom0 Hardware Fingerprint Leaks

[Radoslaw Szkodzinski]

On Tue, Feb 17, 2015 at 11:55 AM, WhonixQubes <whonixqubes at riseup.net> wrote:
> Right.
>
> For example, subdividing the cross-section of privacy/anonymity users by the
> following attributes would no doubt be a privacy/anonymity killer for
> individual human identities...
>
> # of unique combined mixtures of the following attributes:
> - # of Qubes Users

This is relatively easy, because all Qubes users would look similarly
thanks to the local IP address.
Contingent on being able to retrieve local IP or MAC address - which
is not trivial in a privacy-minded setup.
Other information looks like a Fedora system with hardware not
supporting OpenGL.

> - # of Qubes + Tor AnonVM Users

This would require correlating previous step with the list of Tor exit
nodes or using a hidden service for a callback.

> - # of Qubes + Whonix AnonVM Users

This is actually much harder, there's not enough information to
discern between Tor AnonVM and Whonix AnonVM I think.

> - # of CPU Model Info
> - # of CPU Microcode Version

This information is hard to get, unless you crack every one of the
people above - and then, you have to be sure they do not use the same
CPU model.
To do so, you need to break Tor or, say, JavaScript implementation of
most browsers. Then at least access /proc/cpuinfo.
Alternatively, run a plugin which allows access to such information.
(Java comes to mind.)

Fortunately, CPUID does not provide Processor Serial Number in any recent CPU.

Microcode can be either updated when starting Xen via
ucode=<number|scan> and the microcode image in number case or
initramfs with early microcode in scan case.
If Qubes updated the microcode for everyone (a generally good idea),
that could be ignored. Xen 4.4 supports it, so it could be done for
r3.
I think dracut supports adding microcode to the initramfs, so would
just have to add the parameter.

> ...should be pretty easy to reveal individual people through their usage of
> Qubes privacy/anonymity this way.

No. Again, the hardest step is the last one - breaking out of the
sandbox of the web browser.
Once you have local access, there is enough ways to fingerprint
everything imaginable that you've lost.

> Although, AFAIK, other platforms are not totally immune from this. Some just
> have a higher # of total users out in the world, but at their technical
> expense of lacking strong security isolation to protect the integrity of
> their privacy/anonymity systems.

Disable JavaScript, plugins, OpenGL. (e.g. NoScript) Disable cookies.
You are then depending on the web browser's security of this mechanism
and should be left with a vastly smaller TCB.
It also becomes much harder to identify you as a Qubes user as well.

>> Thus, perhaps we should consider distributing Whonix workstation
>> template as an HVM template instead of a PVM one? Fortunately we do have
>> templates support for HVMs, so this should be perfectly possible.
>
>
>
> Assuming there is no feasible way to accomplish this objective with PVMs,
> then implementing the Whonix-Workstation in a HVM template with
> "generic_cpuid" sounds like the right move.

Available free memory in the VM is a much better predictor of the user
and usage than CPUID.
Especially if you allow the VM to balloon (automatically resize memory).
This information is even available from JS in Chrome. (but not Firefox
to my knowledge)

> Another anonymity upshot of HVMs is their, by default, non-seamless fixed
> single windowing. Even though the seamless desktop mode of the new Qubes +
> Whonix platform is sexy and smooth to use, it does expose another
> semi-unique host machine attribute to the AnonVMs, which is the host's
> unique display resolution size and pixel depth (maybe some other related
> stuff too?). Not as bad of an attribute as the host's unique CPU info,

CPUID does not have unique CPU info - Processor Serial Number is not
implemented there in modern CPUs.

> but
> still would be best to make use of the fixed single windowing for AnonVMs so
> this could be generic. Maybe both seamless and non-seamless windowing
> options could be offered for Whonix-Workstation HVM template, since some
> people hate non-seamless.

Why not just resize the browser window by means of the internal window
manager or virtual display size?
(But why are you allowing JS then?)

Much easier than tossing HVM at it, you need to patch exactly one line
in the client VM.
Of course someone might have a weird screen size... but again, this
requires JS to be running.

-- 
Radosław Szkodziński