Merely Cloaking Data May Be Incriminating? 418
n0g writes "In a recent submission to Bugtraq, Larry Gill of Guidance Software refutes some bug reports for the forensic analysis product EnCase Forensic Edition. The refutation is interesting, but one comment raises an important privacy issue. When talking about users creating loops in NTFS directories to hide data, Gill says, 'The purposeful hiding of data by the subject of an investigation is in itself important evidence and there are many scenarios where intentional data cloaking provides incriminating evidence, even if the perpetrator is successful in cloaking the data itself.' That begs the question: if one cloaks data by encrypting it, exactly what incriminating evidence does that provide? And how important is that evidence compared to the absence of anything else found that was incriminating? Are we no longer allowed to have any secrets, even on our own systems?"
Let me get this straight... (Score:5, Interesting)
Of course the difference between this scenario and one where someone merely claims to be unable to decrypt the data is irrelevant.
I thought that we were innocent until proven guilty in this country, not vice versa.
It's called a "warrant". (Score:5, Interesting)
The cops go to a judge and get a warrant based upon whatever evidence they have that a law was broken.
They'd have to have access to it already to see that it was encrypted. And that access should require a warrant.
Again, see the word "warrants" there?
Encrypt EVERYTHING to protect yourself from regular criminals.
But if you are accused of a crime, you have to decide whether the encrypted data will help your case or harm it. And if it will harm your case, will it do more or less harm than refusing to decrypt it?
But there has to be a warrant. Focus your complaints on situations where there aren't any warrants.
I agree (Score:1, Interesting)
Re:What about a physical safe? (Score:1, Interesting)
Re:Why even ask? (Score:5, Interesting)
My experience (Score:2, Interesting)
This immediately prompted me to look at the system closer, and I found evidence, mostly in the form of thumbnails, that the teacher had been downloading and viewing child porn on the laptop. This was definitely a probable cause for me to investigate the laptop, since we owned it. I often wondered how this would hold up if it were a private laptop, or if the police could use that as an excuse to investigate a computer.
Re:The Matter of Privacy (Score:2, Interesting)
However I will agree that it had been ground down a lot in the past few decades.
Re:Why even ask? (Score:3, Interesting)
Copyright all your data now. (Score:3, Interesting)
I wonder if he realizes that if a person has data to which he holds copyright on his hard disks, and then hides it, Gill's recovery software is then in violation of the DMCA anti-circumvention clause? His software is DMCA Grade-A illegal if anyone stores anything, no matter how trivial, that is his own copyright, is legal, and is deliberately hidden from this program.
Anyone with a legal background want to send this guy a "cease and desist" letter? }:^>
--
Toro
(c) 2007 *all rights reserved*
Re:Easy solution (Score:3, Interesting)
Can't prove hidden partition doesn't/does exist (Score:5, Interesting)
The point of a hidden partition is that you can't prove it either way, unless you actually unlock it with the key. So, without the key, I could say, "Yes, there's a hidden partition within this conventional TrueCrypt partition, but I'm not giving you the key!" or I could say, "No, there's no hidden partition," and you wouldn't be able to tell either way.
So, then, you *could* presume that there is a hidden partition --but then that would be on the same order as just presuming that I have something to hide just because I'm using TrueCrypt in the first place. If I don't actually have a hidden partition, and you go looking for one, you're going to spend a pretty long time looking. There's nothing more frustrating than looking for something to prove that it doesn't exist (bug-checking programming sessions, anyone?).
As a matter of course, I do set up TrueCrypt volumes at standard sizes that happen to be much bigger than I need --my usual is 680MB so I can burn the whole thing to a CD. I think all my financial files add up to about 100MB within the 680MB TrueCrypt volume. If you want to go looking in the remaining 580MB for some incriminating evidence --hey, knock yourself out.
Re:Guilty until proven innocent (Score:3, Interesting)
Re:Why even ask? (Score:3, Interesting)
Re:Why even ask? (Score:3, Interesting)
Of course, one can roll their own solution by piping tar or dd through some utility that takes stdin, encrypts it, and passes it to stdout, but in a number of businesses (especially ones subject to SOX, HIPAA, and other regs), one needs to have solutions that are commercial, mainly for CYA/"due diligence" reasons, so one can point fingers at a vendor should something go wrong. gpg is an excellent program and highly secure, but in a lot of environments, programs like that have to pass certifications (FIPS, Common Criteria) to make auditors (and sometimes the SEC) happy, and regardless of how really secure an app is, if it doesn't have the certifications, it is legally risky to use.
I think every backup program from GNU tar on up should have some facility built in for at least AES-128 encryption, and preferably AES-256. However, since this isn't the case, the next best thing is to use something like EncFS so filesystems can be dumped to tape exactly as they are present on the hard disk, but still be encrypted securely. (There is block/device level encryption obviously, but when backing up, one still ends up with plaintext files unless one backs up the whole encrypted image). On the Windows side, at least there are a few utilities like Retrospect available that have had encryption built in for 15+ years. (Retrospect originally started out as a backup program for the Mac in 1989, and was the only one at the time that offered true DES encryption.)