著者: Andrew Gallagher 日付: To: tails-dev 題目: Re: [Tails-dev] Feature #5929 create persistent volume by default
On 2017/04/27 08:10, forgottenbeast wrote: > This way we would be able to write some random data here and there in
> the persistent volume (random locations) at every boot without taking
> much risks regarding the integrity of existing persistent data. Either
> there IS a persistent volume and the encoding could deal with it or
> there isn't and then who cares?
The only reason to zero (randomise) an encrypted partition is so that an
attacker can't be sure how much data has been written to it. In
particular, they shouldn't be able to determine whether it has ever been
mounted - this provides herd cover so that I can plausibly claim that
any data on the partition was made entirely automatically (and randomly)
by Tails and no I don't know the password for it, honest.
But a random pattern of writes is easily distinguishable from a real
filesystem until the partition has been almost completely filled - and
by this point if you've been writing in random locations you've
certainly overwritten your error correction codes many times over. If
you haven't been mounting (and thereby preening) your encrypted
partition on a regular basis, you may be beyond recovery.
A better plan might be to a) randomize only fully-zero blocks, and b) in
the same order that a real filesystem would allocate them. That way the
disk looks more like a real disk, even at intermediate stages. And the
chances of real data getting encoded to a fully-zeroed block are
vanishingly small, so you don't need error correction.
There are buckets of problems with any such approach though. For
example, in a real filesystem not every block that is written gets fully
written - the last block in each file will in general be only partially
used. Inode blocks will also have a different pattern of usage than data
blocks. A statistical analysis of partially-written blocks may be
sufficient to fingerprint a dummy filesystem.
And it gets worse. For example, an attacker could use the amount of
nonzero data on the disk to determine that a particular Tails install
isn't new. If Tails wrote random data to the encrypted partition at a
predictable rate, one could make a guess at how long a particular Tails
drive had been in a running state, and so distinguish a regularly-booted
Tails disk from a freshly-downloaded one. That in itself may be
problematic - and is an *extra* leak over and above what Tails leaks
right now by default. This not only changes the threat model for those
who use encrypted partitions, but also for those who don't - and should
probably therefore not be default behaviour.
But if it's not default behaviour, then you diminish the herd cover,
which defeats the original purpose...
