On Mon, Aug 8, 2016, at 03:32 PM, Joanna Rutkowska wrote:
> Hello,
>
> Is there any special reason why the partition where Tails installs itself
> is
> non-deterministic? It is thanks to differing timestamps on the
> filesystem.
What you have asked about sounds at least similar to an issue I had
reported on this list a while back. I had reported that the checksums
(sha256, sha1, md5, etc.) of the Tails partition (on USB, created by dd)
no longer matched that of the Tails ISO from which said partition was
written. I say "no longer" because there had been a time when these
values did match. That changed at some point with one of the releases
and the change remained for an extended period, through a number of
releases. Then, I believe with the latest release, Tails 2.5, the hashes
for the ISO and the partition of the installation written from the ISO
(via dd, on USB) once again were the same.
The cause of these changes remains a mystery to me.
> This posses a problem for a prudent user who would like to be able to
> verify
> Tails integrity, e.g. by typing:
>
> dd if=/dev/sda1 | sha1sum
How is that different from "sha1sum /dev/sdX*"?
Isn't your version just a lengthier and less simple means of achieving
the identical end: obtaining the checksum of a given partition (in this
case, the sha1 of the partition that Tails installed itself on). Perhaps
I am missing something?
*X for the specific device value, which will obviously change
> This might be especially useful if one uses the stick on various
> computers and
> would like to verify if her USB stick holding Tails installs hasn't been
> modified (e.g. by a malicious BIOS).
Or (and this is obviously applicable even when one always uses his Tails
device on the same computer) that the Tails partition itself was not
altered by a remote attacker (such as while one was online using Tails)
or even a local attacker (such as while one's Tails stick was left
unattended-- even if within a secured space, unless one can somehow be
sure that no one unauthorized entered said space).
Now, of course, this means of verification is still possible even when
the hash of the (verified) ISO does /not/ match that of the partition
created from same ISO-- providing that one made sure to record the hash
of the Tails partition right after creating it (before using it for the
first time and before leaving the device it is contained-on unattended).
But when the checksums of the Tails partition match those of the ISO
that said partition was created from, then one has the additional
advantage of knowing that the actual writing/installation itself was
completed without error or corruption.
>Yes, I'm aware that the first sector
> of the
> disk (/dev/sda) would still differ thanks to different partition sizes.
Right, meaning that an attacker in whatever form (including a
compromised BIOS or other hardware component) could leave the Tails
partition itself untouched, yet alter another section of the device.
What I therefore do, in addition to recording the checksum of the Tails
partition that I created from the ISO (/dev/sdX), is to /also/ record
the checksum of the /entire device/ (USB stick). In this way, I can
presumably be reasonably certain that my stick has not been tampered
with by verifying, at any given time (such as after using it or after
leaving it unattended) that the checksum for the full-device (/dev/sdX)
still matches the one I recorded just after installing Tails on it.
/Persistence/, of course, presents an exception to this; obviously, one
cannot expect the checksum for the persistence partition not to change
with each and every change, no matter how small and insignificant, that
the user makes to said partition.
Having noted that, however, I must /also/ mention an experience I recall
with a USB stick that I had created, with a persistence partition, using
Tails Installer. If I recall correctly, I had found that after each use
of this USB stick to boot and run Tails, the hash for the persistence
partition would change-- /even when I had NOT enabled persistence (or
otherwise consciously accessed the persistence partition) for that
session. Although I do not know the reason for this behavior, I suspect
that it somehow may be very much related to the topic that Ms. Rutkowska
created this thread about.
