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. _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
