HulaHoop (HulaHoop):
Even if the feature exists there are some questions that need to be answered so we introduce something that has real security vs security theater.
Sure.
How many bits of randomness does some range of seconds add? How coarse is the clock resolution before the information it provides is no longer useful to an attacker?
Good question. Some speculative thoughts…
It depends on so many things. For one on adversary capabilities. And on
how many clocks are how much slow or fast.
If the host clock is off by two hours, then I think it’s save to
conclude that adding or removing a 15 minutes offset would not help to
have company.
Let’s say, there are,
- x people who’s clock is 10 second fast.
- y people who’s clock is 60 seconds fast.
- z people who’s clock is 1000 seconds fast.
And so forth.
Having an independent VM clock with a secret offset of plus 30 seconds.
x: measure host: 10
x: measure VM : 30
y: measure host: 60
y: measure VM : 90
z: measure host: 1000
z: measure VM : 1030
x would stand out least.
y would stand out more.
z would stand out most.
This speaks for huge random offsets, so those can obscure host clocks
that are off a lot.
On the gateway the offset may not be too big, otherwise Tor will no
longer be able to connect. So sdwdate cannot connect, cannot take over.
A drift host clock plus too big offset could introduce a Tor
connectivity issue where otherwise none would have been.
On the workstation the offset can be bigger. Not sure how big. One
condition is not being that big, so sdwdate would get confused. Requires
research. Another issue with too big offsets could be the system getting
confused by it. Messed up logs. Confused server software. Requires
research what else. Perhaps most of this could be prevented with some
clever systemd dependencies. On the workstation also the offset is more
important, because it is more likely to get compromised.
We can prevent strange web fingerprints with hugely offset clocks by
blocking all traffic except sdwdate until sdwdate finished after boot.
This was the plan anyhow.
My hope is explaining clock correlation attacks real well, and having an
independent VM clocks becoming the standard, so adversaries won’t even
attempt clock correlation attacks anymore, because there hopefully will
be random offsets everywhere.
Depending on the answers a known offset may be enough.
I don’t think a public known offset would work. Because then adversaries
would always do a calculation with public known offset removed.
Note that from previous tests the clock always differed from the host’s when I checked hwclock’s numbers. hwclock in the VM was UTC by the way. Despite the best attempts to keep both clocks synced they always differed.
Did you disable boot clock randomization? Not using it will surely mess
up this test.
Did you try test with non-Whonix, Debian VMs?