What, exactly, is that supposed to mean?

That being said the current business 'prayer' of soft skills, has been an utterly massive boon to military personnel of any rate.

Besides, a "smart" Geeksquad employee could just backdate the comptuer's clock or manipulate the file creation time directly to make it look like the image was placed there when the owner had the computer in his posession.

There are lots of advanced techniques to manipulate various aspects of Time related artifacts, but there are also lots of advanced techniques for determining whether a system has been tampered with. A skilled person might be able to erase evidence of exactly what they did, but often this creates artifacts or even an absence of artifacts that can be used to determine that someone tampered with the system in an attempt to cover his tracks.

I specialize in forensics in the context of incident response, so I don't typically run into anti-forensic techniques as sophisticated as law enforcement analysts may encounter. Perhaps there are ways to completely avoid detection. However, I imagine it would be difficult.

That actually sounds like an interesting idea. Would it be useful in any way and would it be be feasible in a way that couldn't be tampered with?

A proper encryption protocol consists of not only the encryption itself, but also authentication, verification and integrity checks. These are for protection against things like replay-attacks and indeed, tampering.

IIRC, booting a laptop with an encrypted FS, normally you'd enter your password, it'd apply a key-generating function (to turn the password into a proper 256bit AES key, or whatever's required), discard the password from memory and then use the key for operating a symmetric cipher (like AES) on the FS's read/write operations.

However, that doesn't quite work, it's not enough to do just that. An encrypted FS also needs authentication and verification, otherwise you open up yourself against all sorts of sneaky attacks stripping your encryption. So AFAIK, the system also keeps checksums and signatures with HMACs or something.

Admittedly, I don't know the exact details. One thing I'm not sure about is if there's the option of having some public/private key available for a bit of assymmetric encryption. Performance-wise you can't afford running that over the whole data stream (but who does that) because it's so much slower than symmetric encryption (which is why we have handshake protocols). But maybe do it once per block (or N blocks), adding cryptographic signatures to whatever's written. Blocks would be timestamped and these timestamps would be included in the signature too[0].

I could imagine, booting, without the password, would give you read-only access. Without password, the FS can only access the public key. The read operation uses this key to check the signatures on whatever blocks it's called to read. The write operation cannot be used to write any valid blocks, because it can't sign them without the private key (you can still trash blocks by overwriting them with invalid data, but you could do that anyways). Booting with a password allows the FS to decrypt the private key, allowing both read and write access.

Basically you'd have an encrypted FS, with the encryption left off but the verification left on.

For a Geeksquad-style attack you even get another layer of protection because without the password, the whole system is read-only. The "evil website put CP in my browser cache" attack is still possible because you'd be logged in, however in that case, at least you got verifiable timestamps on the written blocks, as well as your browser history, that can be analysed to show there was no intent to get, save or view this data.

I think this could be made to work in concept, in theory. Question is if you'd really want to use it though, authenticated verifiable timestamps on all your data, can also be a liability. Because people who "got nothing to hide" are just unaware that even they in fact, do. It means that for whatever you do on your computer, whoever can access the harddisk, can verify that whatever is on it was done by you, and only by you, as well as an undeniable proof of when it was done. That means zero privacy. Forward secrecy won't help here, because the whole point (verifiable authenticated timestamps) is about not having it. It may be nice for certain company laptops, however if it was my own machine, I'd prefer full-disk encryption, get the same protection and the privacy.

[0] while at it, why not also tag it with other metadata, such as origin (local or remote / where) and the process or application that issued the write command

If it's done in a competent way, the disk can be altered. Code can be installed on the hardware that will plant evidence after the victim returns home.

Worse: many filesystems don't note creation time but change time. I'd have to check what the status is for NTFS (the most likely consumer FS), but that's the case for virtually all Unix-and-similar filesystems: ext3/4, HFS, etc.

NTFS tracks creation time also, and it's available as one of the columns to sort by in Explorer.

[1] https://lwn.net/Articles/397445/

A chain of custody with extremely rigorous procedures and protocols is the only reason a forensic expert has some level of trust.

Without that, and with incentive, this becomes nothing more than a farce.

[0] https://www.howtogeek.com/203154/how-to-change-created-or-mo...

[1] https://www.freebsd.org/cgi/man.cgi?query=touch&sektion=1

I'll still maintain it's not universally available on filesystems. And is unreliable (many allow changing this value, see, e.g., touch(1)). And that unallocated space lacks filesystem metadata.