On 27/05/2021 07:56, Michael Kjörling wrote: > On 26 May 2021 10:48 +0200, from u961866@xxxxxxxxxxxx (Valdez): >> Could a forensic investigation of an unmounted LUKS partition on a >> USB flash drive used to run Tails reveal any information about the >> date when the LUKS partition was created? > > Whether the storage device is a SATA SSD, USB flash drive, rotational > fixed disk, floppy disk, or something you keep only in your brain, is > immaterial to LUKS, as long as it can accurately retain and allow > reading back high-entropy data. > > I'm also going to assume that when you say "LUKS partition", you mean > a LUKS container. LUKS containers do not necessarily live inside > partitions. > > Also, I'm not familiar with Tails specifically. > > However, the LUKS on-disk formats are linked to from the front page of > the Wiki, at <https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home>. > > I'm pretty sure there are no dedicated fields for such timestamps in > either on-disk format; I don't see how having them would serve any > valid purpose. However, you certainly can look over the format specs > if you're curious; for what they cover, they should be every bit as > authoritative as anything you'll get in replies here. You can also > compare them to the output of, say, `cryptsetup luksDump > --dump-master-key` on a dummy container. > > Be aware that LUKS 2 is capable of storing arbitrary data in the > header. Something would still need to put such a timestamp there, of > course, but if this is a concern to you, you might consider sticking > with the (older and less featureful) LUKS 1 format. As an alternative, > you could set your computer's time to some other value before creating > the container; _if_ something stores such a timestamp, it would then > reflect that time value, not the actual real-world time of container > creation. > > That said, some details from the LUKS header might provide clues in a > very gross sense; for example, encryption algorithm, key size and key > derivation function used for the container or a key slot might _hint_ > at which version of the LUKS tools were _possibly_ used to create or > last update it, because defaults have slowly changed over time. But > then you'd probably be looking at a likely time span of years. Thanks for the excellent summary! Just a few more points (maybe we can later add this to FAQ): - In fact, not storing date/access time anywhere in LUKS2 was intention, I just forgot to mention it in docs. (Of course we cannot avoid this if someone implements own token metadata extension.) - LUKS2 can increase seqid (sequence id) if autocorrection updates the header. It is a simple counter, so you can just say that there was some operation (but if you have an old copy, you can say it anyway :) - libcryptsetup implements also other formats VeraCrypt, BitLocker ... (I know Tails used VeraCrypt compatible implementation in libcryptsetupo to access pre-formatted disks.) And all _metadata_ for these foreign formats are strictly read-only if accessed through libcryptsetup (even if there is some field that should be updated, libcryptsetup never writes anything there, we even do not have code for it. You cannot for example update passphrase etc through libcryptsetup.) Of course, once mounted, upper layer like filesystem can update decrypted data (and in the case of BitLocker even partially metadata as it is shared/interleaved with NTFS metadata areas). But that is outside of our code responsibility. Milan _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
