7 ms·

"how does the government intend to prove beyond any reasonable doubt that the Geek Squad employees themselves didn't put the alleged porn pictures on the device

by Esau 10y ago

"how does the government intend to prove beyond any reasonable doubt that the Geek Squad employees themselves didn't put the alleged porn pictures on the device?" Well, that's the rub, isn't it? We're talking about non-law enforcement personnel who are going to be rewarded if they find something. And at that salary level, where people are frequently living month to month, it is indeed conceivable that somebody would place evidence just for the money.

Spooky23 10y ago
When I worked at a big computer chain in the 90s, my coworkers would sacrifice their left pinky for a $21 spiff for moving a Viewsonic monitor. $500 would be a crazy motivator, especially for the ex-military types who were drifting around after the service.
- Vadoff 10y ago
  Well maybe you could have an expert identify when that file was placed onto your computer. If it coincides with when the Geek Squad member worked on your computer, then that guy will (hopefully) go to jail for a long time.
  - rjbwork 10y ago
    Easy to forge creation times.
    - dredmorbius 10y ago
      Unallocated space doesn't have filesystem entries, hence, no file change, access, or modification times. 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.
      - barrkel 10y ago
        EXT3/4 does in fact track creation time, but the Unix-style fstat() doesn't have a field to return creation time. You can use debugfs to retrieve it once you have the inode and device: http://unix.stackexchange.com/questions/50177/birth-is-empty-on-ext4/50184#50184 http://unix.stackexchange.com/questions/50177/birth-is-empty... NTFS tracks creation time also, and it's available as one of the columns to sort by in Explorer.
        0x09 10y ago
        The BSDs, Windows, OS X, and Mac OS classic and their corresponding filesystems all supported this for decades. Linux is the only major holdout, because according to Linus, "it's all totally useless and people can't even agree on a name." [1] [1] https://lwn.net/Articles/397445/ https://lwn.net/Articles/397445/
        shakna 10y ago
        Yet creation time is still useless in this case, because forging it is still trivial [0][1]. 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-modified-timestamps-for-files-and-folders/ https://www.howtogeek.com/203154/how-to-change-created-or-mo... [1] https://www.freebsd.org/cgi/man.cgi?query=touch&sektion=1 https://www.freebsd.org/cgi/man.cgi?query=touch&sektion=1
        dredmorbius 10y ago
        Thanks for that. I know that the inode structure doesn't, or at least didn't return this, for a long time (occupational hazard: outliving your education's "best used by" date). Which was why I'd already edited the initial "most" to "many" describing filesystems above (prior to posting). 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.
  - Johnny555 10y ago
    Disk blocks aren't timestamped, and the FBI is even looking at disk free space, so there may not even be a directory entry that can show when the image was placed there. 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.
    - oliv__ 10y ago
      > Disk blocks aren't timestamped 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?
      - tokenizerrr 10y ago
        It can always be tampered with if you have access to the hardware
        tripzilch 10y ago
        If we assume they can't break full-disk encryption (which is not unlikely), are you certain? 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
  - darpa_escapee 10y ago
    Suppose an incompetent employee plants evidence on a computer. The accused will have to mount a defense and pay an expert to examine the evidence and testify. Maybe a jury will believe it. 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.
  - michaelmrose 10y ago
    You realize that it would be trivial to change this right and utterly impossible to prove right?
- aphextron 10y ago
  >$500 would be a crazy motivator, especially for the ex-military types who were drifting around after the service. What, exactly, is that supposed to mean?
  - brandnewlow 10y ago
    I assume he's referring to Desert Storm veterans who happened to be facing weak job prospects
  - lithos 10y ago
    Quite a few military personnel pick up few hard skills. Unless you're in a trade/rate with with high knowledge requirements it seemed like they preferred it to keep some people in. That being said the current business 'prayer' of soft skills, has been an utterly massive boon to military personnel of any rate.

by Esau 10y ago

Spooky23 10y ago

When I worked at a big computer chain in the 90s, my coworkers would sacrifice their left pinky for a $21 spiff for moving a Viewsonic monitor. $500 would be a crazy motivator, especially for the ex-military types who were drifting around after the service.

Vadoff 10y ago
Well maybe you could have an expert identify when that file was placed onto your computer. If it coincides with when the Geek Squad member worked on your computer, then that guy will (hopefully) go to jail for a long time.
- rjbwork 10y ago
  Easy to forge creation times.
  - dredmorbius 10y ago
    Unallocated space doesn't have filesystem entries, hence, no file change, access, or modification times. 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.
    - barrkel 10y ago
      EXT3/4 does in fact track creation time, but the Unix-style fstat() doesn't have a field to return creation time. You can use debugfs to retrieve it once you have the inode and device: http://unix.stackexchange.com/questions/50177/birth-is-empty-on-ext4/50184#50184 http://unix.stackexchange.com/questions/50177/birth-is-empty... NTFS tracks creation time also, and it's available as one of the columns to sort by in Explorer.
      - 0x09 10y ago
        The BSDs, Windows, OS X, and Mac OS classic and their corresponding filesystems all supported this for decades. Linux is the only major holdout, because according to Linus, "it's all totally useless and people can't even agree on a name." [1] [1] https://lwn.net/Articles/397445/ https://lwn.net/Articles/397445/
        shakna 10y ago
        Yet creation time is still useless in this case, because forging it is still trivial [0][1]. 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-modified-timestamps-for-files-and-folders/ https://www.howtogeek.com/203154/how-to-change-created-or-mo... [1] https://www.freebsd.org/cgi/man.cgi?query=touch&sektion=1 https://www.freebsd.org/cgi/man.cgi?query=touch&sektion=1
      - dredmorbius 10y ago
        Thanks for that. I know that the inode structure doesn't, or at least didn't return this, for a long time (occupational hazard: outliving your education's "best used by" date). Which was why I'd already edited the initial "most" to "many" describing filesystems above (prior to posting). 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.
- Johnny555 10y ago
  Disk blocks aren't timestamped, and the FBI is even looking at disk free space, so there may not even be a directory entry that can show when the image was placed there. 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.
  - oliv__ 10y ago
    > Disk blocks aren't timestamped 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?
    - tokenizerrr 10y ago
      It can always be tampered with if you have access to the hardware
      - tripzilch 10y ago
        If we assume they can't break full-disk encryption (which is not unlikely), are you certain? 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
- darpa_escapee 10y ago
  Suppose an incompetent employee plants evidence on a computer. The accused will have to mount a defense and pay an expert to examine the evidence and testify. Maybe a jury will believe it. 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.
- michaelmrose 10y ago
  You realize that it would be trivial to change this right and utterly impossible to prove right?
aphextron 10y ago
>$500 would be a crazy motivator, especially for the ex-military types who were drifting around after the service. What, exactly, is that supposed to mean?
- brandnewlow 10y ago
  I assume he's referring to Desert Storm veterans who happened to be facing weak job prospects
- lithos 10y ago
  Quite a few military personnel pick up few hard skills. Unless you're in a trade/rate with with high knowledge requirements it seemed like they preferred it to keep some people in. That being said the current business 'prayer' of soft skills, has been an utterly massive boon to military personnel of any rate.