Some phones are encrypted if you add a passcode, but won't be unless you do. Also AFAIK android still isn't by default event when a passcode is set.
One of the problems with doing it by default is the consequences of a lost password. On a consumer device (where there's unlikely to be an admin backup password) a lost/forgotten password can result in the user losing all their data.
Once people get to the point of storing all personal data off machine (e.g. OneDrive / icloud) it would make more sense to have this kind of thing enabled by default.
Just when I though I know everything about how computer works, here they are talking about freezing ram attack. I didn't even imagine this as a possibility.
So, it's obviously hard to defend against a freeze attack when the computer is sleeping - because the key is still needed.
But I feel like disk encryption software should, when the computer is being shut down, prepare some random data and write over the encryption key to prevent information leakage in the moments after shutdown. This, combined with some hardware intrusion detection system would help a lot, wouldn't it? Or am I missing something?
There's a neat implementation of AES that uses only registers and never has the key in RAM after boot. I forget the name right now, but it's pretty fucking awesome. IIRC it puts the key into debug registers, then disables access to those registers. It calculates the key schedule on-the-fly for each block it encrypts, and it performs decently with AES-NI. So neither the key, nor any of intermediate pieces, are ever in RAM, just in registers.
Recommending BitLocker and OSX HD encryption I feel is a diservice to the public. I wouldn't put it past them to already have backdoors built in. Let alone they are both proprietary and not open to public audit. I guess we are suppoed to take their word [1]???
I really get a twisted feeling about people deposing Microsoft Bitlocker or OSX filevault due to potentially being backdoored- yet still running their operating systems, and any third party stuff you give full access to.
I mean, I'm not trying to be all tin-foil, but trusting one source is much better than trusting two. (one for live OS security, another for offline data protection)
You make the decision to trust some entity 'X' that has some probability of being compromised. If it isn't compromised you're good and if it is you're screwed, but as you add additional entities each introduces an additional individual probability of being 'bad'. There's an argument that it's better to trust one entity entirely in order to have a greater chance of being fully 'safe' rather than split your trust and having a higher chance of being partially compromised since partial compromise is often equivalent to being fully compromised.
Also open to public audit doesn't mean anyone has actually looked at them/assured their security to any degree.
the only product that I'm aware of in this category that has received that kind of scrutiny is truecrypt which has been abandonend by its original developers and doesn't have a license that is (AFAIK) conducive to someone else taking over the project.
That is the kicker, what to recommend. If at all possible I would recommend Linux or BSD. I am happy to see the article cover Ubuntu encryption. Also BSD has an embassy grade encryption, that has slipped from mind mind at the moment.
I do realize that it isn't feasible to jump ship and move to another platform for everyone. The whole Truecrypt is a bummer since it was a good cross platform tool.
I'm a typical developer and I think I speak for the vast majority of people when I say that my concern is not with top level government agencies decrypting my hard drive. My concern is with me losing my computer or having it stolen by a petty thief, in which case I feel that the proprietary built-in encryption tools offered by Microsoft and Apple are perfectly suitable.
I agree that for keeping the TSA Joe out of a laptop is is great. The issue comes with educating non technical people, which this article feels like it is aimed at, with a enryption methods that we can't gurantee are sound.
While it may stop petty data theft we have seen how these backdoors trickle down and before you know it your local police department is abusing it left and right. An example of technology that has been package and sold is the Stingray for cell phones. Even though this is more of a nasty feature of cellphones that the Stringray exploits what is stopping a BitLocker or OSX exploit to be commoditized?
Security involves tradeoffs. If you are a non-technical person with typical security needs, the encryption functions that are built into operating systems offer a lot of security with almost no tradeoff other than clicking a button to enable it.
Once you start layering on additional requirements for the type of encryption you are using (e.g. has to be open source, has to be audited, needs to offer no evidence of installed OS, etc.), you are creating a myriad of hoops to jump through that a non-technical person is more likely inclined to just not jump through at all.
If you are someone with security requirements that need to guarantee that no one will ever be able to access your data, including the police or feds who might have access to secret backdoors, I would hope it's common sense that you should be doing a lot more research on encryption rather than relying on a random security article aimed at non-technical people.
> when I say that my concern is not with top level government agencies decrypting my hard drive.
It's great that you have risk-assessed your needs.
It's a shame that the title says "like you mean it", and not "for tamper resistance against most people, but probably not well funded government agencies".
> A new generation of inexpensive disk drive enclosures using hardware encryption and RFID keys do not fulfil the promises of their publicity. The adverts claim 128-bit AES hardware encryption, but they don't tell us how it is used
> But the FBI, concerned about its ability to fight crime — specifically, child pornography — apparently repeatedly asked Microsoft to put a backdoor in the software. A backdoor — or trapdoor — is a secret vulnerability that can be exploited to break or circumvent supposedly secure systems.
>For its part, the FBI categorically denies asking for such access, telling Mashable that the Bureau doesn't ask for backdoors, and that it only serves companies lawful court orders when it needs to access users' data. (And, legally, it would still need a warrant even if a backdoor did exist.)
There's a difference between "being asked to" and "actually doing it". If you think that Microsoft or Apple would backdoor their FDE to appease the FBI or any other federal agency is to assume that they have no interest in their customer base and would rather piss all over it.
Besides, LUKS was "backdoored" by the FBI by simply having two agents behind someone's back and then having another agent grab the laptop as the individual turned around.
There has been some analysis of FileVault FDE, as well as an implementation of an open source library to read it. [1] The short answer is that they couldn't break it. While it'd be better if the whole thing was open source, at least the fact that I can understand the on-disk layout and algorithms used is comforting.
with hardware support for encryption in CPUs and directly on the drives themselves the hit on performance isn't anything like as bad as it used to be with pure software solutions
I think the best / most secure computer you can use today is a libreboot GM45 thinkpad with FDE, including /boot. The implications of this are big, both in security and in plausable deniability. Look at the case of Jeff Feldman [1], and how having a detectable OS made him liable for the hard disk. If they can't show that the drive contains some kind of OS or that it's not gibberish, you cannot be forced to unencrypt them (don't quote me on this, I'm not entirely sure if I'm speaking the truth.)
But if I'm right, having a visible /boot partition is enough to show that there is some kind of OS.
With Grub2 written to the board itself, you can get around that. [2]
I don't see how the article you linked to [0] indicates a detectable OS in any way shape or form.
Rather, the issue is that if it cannot be shown that you do know the password, then ownership of the drive cannot be determined. Entering the password is equivalent to admitting ownership, and therefore would be self-incriminating.
The article indicates that the FBI decrypted one drive and found evidence that it belonged to Feldman:
>According to the order (PDF), after devoting “substantial resources” in the case, FBI agents apparently have been able to decrypt one of the drives. The government argued that because it had found “numerous files which constitute child pornography,” “detailed personal financial records and documents belonging to Feldman,” and “dozens of personal photographs of Feldman," Feldman therefore has “access to and control over” the set of drives.
In an adversarial judicial system, can a judge trust the prosecution to not tamper with digital evidence? What can the defense do in a situation where the prosecution plants an identical storage device (hard disk drive, ssd, flash drive) that contains cp specimen?
Does the judge simply take prosecution's word? If so, why can't they just take the defense's word that they don't know the password?
> In an adversarial judicial system, can a judge trust the prosecution to not tamper with digital evidence?
The judge doesn't have to trust the evidence, the judge just allows the prosecution to present it, and allows the defense to present whatever they have to rebut it, including challenges to its provenance, counterevidence, etc.
For those who use BitLocker: although it is set up to use numeric-only PINs by default, you can configure this to allow any character - which would presumably increase the search space of brute force attacks against the PIN.
The relevant Group Policy setting is "Allow enhanced PINs for startup", and can be found in Windows Components → BitLocker Drive Encryption → Operating System Drives.
The big question is: is your PIN used only for TPM access? Or is the PIN itself combined after unlocking the TPM?
How it should work is that one hash of your PIN is used to unlock the TPM. Then another hash of the PIN is used to mix into the key the TPM provides. That way directly compromising the TPM doesn't provide full access.
This is probably strictly obsolete by using a long PIN. But it feels nice to have a TPM, as it's one more piece the attacker needs. If they steal the disk or fuckup the TPM, then the data's gone, even if you reveal your PIN.
(ATM, I use Bitlocker, then encrypt my VMs with EFS keyed off a certificate stored on a smartcard. Then I Bitlocker the VM drive itself. It's silly, but that way I get a range of hardware plus brain-stored password. [I don't need it any more, it's just a leftover setup from my BTC experiments.] I also put tamper proof seals all over my laptop, but it requires active work to check them and note the serial number on each one.)
I wondered that too - apparently in Vista the PIN was only used to authenticate to the TPM and retrieve the volume master key (which in turn protects the key used to actually encrypt the drive).
More pleasingly however, in Windows 7 and onwards it is used to encrypt the volume master key as well, in pretty much the way you describe.
I'm a Linux desktop/laptop user and just wanted to point out that LUKs encryption is built right into the RHEL / Fedora installer and works like a champ.
Well, back when I used windows TrueCrypt was still a thing.
Depending on your threat model, probably still TC though.
If your threat model is the NSA, I'd advise you to not use windows anyways. Plus, if it does turn out TC has a major flaw, someone abusing it might make a noise. And as far as I'm aware the TC audit also hasn't found anything serious so far.
If you aren't betting your life on it, I think you're still fine with TrueCrypt, Plus, encrypting your full drive with it is something my mother could do. Next, next, next done, at least that's how I remember it.
Edit: Thinking about it, this is firstlook.org, maybe they know something we don't, but recommending BitLocker over TC sill seems like a stretch.
Thing about TrueCrypt is that it was built for a specific purpose. Just having the app installed is like walking around wearing lockpicks and saying that you don't pick locks, you're just wearing them for decoration.
If it was called 'ext4' (yes, deliberately pick a conflicting name with something that already exists in widespread use, and provide a drop-in replacement) it might be better. This would be the equivalent of walking around with paper clips instead, which has much better plausible deniability. Bonus points if it could be engineered to actually mount as an ext4 volume if someone actually tried.
> But unfortunately, laptops have ports that have direct memory access, or DMA, including FireWire, USB, and others.
USB doesn't exposes DMA.
“Examples of connections that may allow DMA in some exploitable form include FireWire, ExpressCard, Thunderbolt, PCI and PCI Express.” – http://en.wikipedia.org/wiki/DMA_attack
The block-quote incorrectly mentions DMA over USB, but the described attack uses Windows AutoRun. The comments discuss a demonstrated FireWire iPod based DMA attack, and that USB doesn't expose DMA.
If you're crossing borders with electronic stuff, simply don't bring anything personal. Access it remotely. You'll only be out hardware should the hardware be confiscated, and you'll have no big privacy breach should you have to boot the machine to show to customs.
Clear cache / cookies beforehand, or use the browser in a mode that clears on shutdown. Use suspend / hibernate when not crossing borders, but do a proper shutdown when going through borders.
Carrying valuable data around then trying to protect it by encrypting it, while simultaneously going through borders, is just asking for trouble IMO. You'll look like a complete freak should you be picked on, very suspicious.
Well it's probably easier and cost effective for "them" to access your remote data (and they probably already have with their dragnet surveillance programs) than to decrypt your laptop.
50 comments
[ 8.4 ms ] story [ 88.9 ms ] threadOne of the problems with doing it by default is the consequences of a lost password. On a consumer device (where there's unlikely to be an admin backup password) a lost/forgotten password can result in the user losing all their data.
Once people get to the point of storing all personal data off machine (e.g. OneDrive / icloud) it would make more sense to have this kind of thing enabled by default.
But I feel like disk encryption software should, when the computer is being shut down, prepare some random data and write over the encryption key to prevent information leakage in the moments after shutdown. This, combined with some hardware intrusion detection system would help a lot, wouldn't it? Or am I missing something?
Edit: Here it is: Tresor: http://www1.informatik.uni-erlangen.de/tresor
[1] http://mashable.com/2013/09/11/fbi-microsoft-bitlocker-backd...
I mean, I'm not trying to be all tin-foil, but trusting one source is much better than trusting two. (one for live OS security, another for offline data protection)
I'm not following your 'trusting one source is much better than two'. Care to expand?
It's the same idea that leads the Tor network to use entry guard nodes: https://www.torproject.org/docs/faq.html.en#EntryGuards
Also open to public audit doesn't mean anyone has actually looked at them/assured their security to any degree.
the only product that I'm aware of in this category that has received that kind of scrutiny is truecrypt which has been abandonend by its original developers and doesn't have a license that is (AFAIK) conducive to someone else taking over the project.
I do realize that it isn't feasible to jump ship and move to another platform for everyone. The whole Truecrypt is a bummer since it was a good cross platform tool.
While it may stop petty data theft we have seen how these backdoors trickle down and before you know it your local police department is abusing it left and right. An example of technology that has been package and sold is the Stingray for cell phones. Even though this is more of a nasty feature of cellphones that the Stringray exploits what is stopping a BitLocker or OSX exploit to be commoditized?
Once you start layering on additional requirements for the type of encryption you are using (e.g. has to be open source, has to be audited, needs to offer no evidence of installed OS, etc.), you are creating a myriad of hoops to jump through that a non-technical person is more likely inclined to just not jump through at all.
If you are someone with security requirements that need to guarantee that no one will ever be able to access your data, including the police or feds who might have access to secret backdoors, I would hope it's common sense that you should be doing a lot more research on encryption rather than relying on a random security article aimed at non-technical people.
It's great that you have risk-assessed your needs.
It's a shame that the title says "like you mean it", and not "for tamper resistance against most people, but probably not well funded government agencies".
http://www.h-online.com/security/features/Enclosed-but-not-e...
> A new generation of inexpensive disk drive enclosures using hardware encryption and RFID keys do not fulfil the promises of their publicity. The adverts claim 128-bit AES hardware encryption, but they don't tell us how it is used
She does a nice write up.
>For its part, the FBI categorically denies asking for such access, telling Mashable that the Bureau doesn't ask for backdoors, and that it only serves companies lawful court orders when it needs to access users' data. (And, legally, it would still need a warrant even if a backdoor did exist.)
There's a difference between "being asked to" and "actually doing it". If you think that Microsoft or Apple would backdoor their FDE to appease the FBI or any other federal agency is to assume that they have no interest in their customer base and would rather piss all over it.
Besides, LUKS was "backdoored" by the FBI by simply having two agents behind someone's back and then having another agent grab the laptop as the individual turned around.
[1] https://www.lightbluetouchpaper.org/2012/08/06/analysis-of-f...
But if I'm right, having a visible /boot partition is enough to show that there is some kind of OS.
With Grub2 written to the board itself, you can get around that. [2]
[1]: http://arstechnica.com/tech-policy/2013/05/28/in-reversal-ju...
[2]: http://libreboot.org/docs/gnulinux/encrypted_trisquel.html
There is always a trade-off in this kind of case between security and usuability
Rather, the issue is that if it cannot be shown that you do know the password, then ownership of the drive cannot be determined. Entering the password is equivalent to admitting ownership, and therefore would be self-incriminating.
The article indicates that the FBI decrypted one drive and found evidence that it belonged to Feldman:
>According to the order (PDF), after devoting “substantial resources” in the case, FBI agents apparently have been able to decrypt one of the drives. The government argued that because it had found “numerous files which constitute child pornography,” “detailed personal financial records and documents belonging to Feldman,” and “dozens of personal photographs of Feldman," Feldman therefore has “access to and control over” the set of drives.
Edit: Forgot link.
[0]http://arstechnica.com/tech-policy/2013/05/28/in-reversal-ju...
Does the judge simply take prosecution's word? If so, why can't they just take the defense's word that they don't know the password?
Alternatively, the defendant can take the stand and declare that they don't know the password and the porn isn't theirs.
Then the jury decides who to believe.
The judge doesn't have to trust the evidence, the judge just allows the prosecution to present it, and allows the defense to present whatever they have to rebut it, including challenges to its provenance, counterevidence, etc.
The relevant Group Policy setting is "Allow enhanced PINs for startup", and can be found in Windows Components → BitLocker Drive Encryption → Operating System Drives.
How it should work is that one hash of your PIN is used to unlock the TPM. Then another hash of the PIN is used to mix into the key the TPM provides. That way directly compromising the TPM doesn't provide full access.
This is probably strictly obsolete by using a long PIN. But it feels nice to have a TPM, as it's one more piece the attacker needs. If they steal the disk or fuckup the TPM, then the data's gone, even if you reveal your PIN.
(ATM, I use Bitlocker, then encrypt my VMs with EFS keyed off a certificate stored on a smartcard. Then I Bitlocker the VM drive itself. It's silly, but that way I get a range of hardware plus brain-stored password. [I don't need it any more, it's just a leftover setup from my BTC experiments.] I also put tamper proof seals all over my laptop, but it requires active work to check them and note the serial number on each one.)
More pleasingly however, in Windows 7 and onwards it is used to encrypt the volume master key as well, in pretty much the way you describe.
Microsoft's submissions for FIPS validation have some good detail on this - Windows 7 [see section 7]: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/1..., others: https://www.google.com/search?q=site:csrc.nist.gov+inurl:140...
This could mean keeping a lot of data encrypted online, with keys being remembered (and possibly backed up in a safe at home incase you forget)
That is obviously simply not true. There is no user friendly GUI way to do it, but it is definitly doable, and that's what they should have written.
Also, recommending BitLocker, and not having the main guide for something more user friendly and open source?
Depending on your threat model, probably still TC though. If your threat model is the NSA, I'd advise you to not use windows anyways. Plus, if it does turn out TC has a major flaw, someone abusing it might make a noise. And as far as I'm aware the TC audit also hasn't found anything serious so far.
If you aren't betting your life on it, I think you're still fine with TrueCrypt, Plus, encrypting your full drive with it is something my mother could do. Next, next, next done, at least that's how I remember it.
Edit: Thinking about it, this is firstlook.org, maybe they know something we don't, but recommending BitLocker over TC sill seems like a stretch.
If it was called 'ext4' (yes, deliberately pick a conflicting name with something that already exists in widespread use, and provide a drop-in replacement) it might be better. This would be the equivalent of walking around with paper clips instead, which has much better plausible deniability. Bonus points if it could be engineered to actually mount as an ext4 volume if someone actually tried.
https://ssd.eff.org/en/module/how-encrypt-your-windows-devic...
USB doesn't exposes DMA.
“Examples of connections that may allow DMA in some exploitable form include FireWire, ExpressCard, Thunderbolt, PCI and PCI Express.” – http://en.wikipedia.org/wiki/DMA_attack
Schneier on Security — Hacking Computers Over USB https://www.schneier.com/blog/archives/2006/06/hacking_compu...
The block-quote incorrectly mentions DMA over USB, but the described attack uses Windows AutoRun. The comments discuss a demonstrated FireWire iPod based DMA attack, and that USB doesn't expose DMA.
Clear cache / cookies beforehand, or use the browser in a mode that clears on shutdown. Use suspend / hibernate when not crossing borders, but do a proper shutdown when going through borders.
Carrying valuable data around then trying to protect it by encrypting it, while simultaneously going through borders, is just asking for trouble IMO. You'll look like a complete freak should you be picked on, very suspicious.