If you need to ask that, then you're not the one encrypting your data in the first place.
How does /home encryption fare if you have it on a separate drive?
Originally Posted by curaga
in theory a suitable SSD would carry the OPAL TCG sticker, or one of the FIPS accreditations.
however, I seem to remember long ago that Intel had to offer to replace a particular model of SSD because they had bad firmware in it which didn't encrypt the data to the required standard, and due to the way the drive's microcontroller was programmed, it wasn't possible to reprogram it.
ahah, finally found it after much googling:
what are you talking about? since when does it matter writing long continues 1s (or 0s)?
Originally Posted by speculatrix
the only thing where external encryption can affect the liftetime of a ssd is on controlers that do compression. it hinders compression which means that you write more bytes than with compression. in such a case it would be better to first compress and then encrypt which means that the compression must also be dones externally (e.g. by software).
but this has nothing to do with long runs of 1s or 0s. such data is actually extremly good compressable.
maybe i understood you wrong.
For some work you MUST encrypt, no matter what the penalty
My experience is encrypting an SSD or a flash drive works fine and stays reasonablly fast as long as you set aside about a third of it as unallocated space. This makes sure that the controller can find unused blocks to erase. If you don't do this, all cheap flash drives can become very slow once the encrypted partitions have ever been filled. This problem doesn't seem to be as bad on SSDs but they still do slow down when filled in this way.
Originally Posted by speculatrix
As for lifespan, for what I do an early wearout is far to be preferred to the consequences of not using encryption. I had a computer stolen by a police raid, I was damned glad that one was encrypted, so this is something I don't compromise on.
I would not trust encryption provided by the drive, since for my work the NSA is the presumed worst-case adversary and hardware back doors into that are likely, just as was the case for ATA security set passwords. There was even a criminal conviction in the US where someone thought their data was protected by setting an ATA disk access password which the FBI was able to quickly bypass with the help of some kind of master key the manufacturer provided.
If you don't encrypt the OS, there are just too many places an attacker with physical access while you are out could drop a keylogger or a replaced binary, as physicall access=root. Encryption is the only thing that can write protect a disk against an attacker booting from something else. When the OS is encrypted too, only the /boot partition can be usefully written to, in what is known as an "evil maid" attack. The /boot partition is a hell of a lot easier to hash check than a whole operating system, so long as you do not mount it after booting and before hash checking.
Last edited by Luke; 05-20-2013 at 10:39 PM.
I might be wrong. Though I've used up my allowance of errors for this year :-)
Originally Posted by a user
I was too lazy to find the citation, but since you challenged me...
"Most modern SSDs come with some form of hardware encryption. On these drives with hardware encryption, itís usually permanently turned on - all data written to the NAND is typically stored in encrypted form. This stems from the fact that all writes to NAND had to be scrambled to begin with (writing long repeated strings of data to NAND can cause problems for data retention)."
Phew, I'm right. As usual. :-D
If anyone is to encrypt their data, why not do it the way it's most secure and leaves the least open risks with reasonable effort?
IMO, this excludes the proprietary mechanisms in place in practically all current SSD's that have some sort of built-in encryption functionality. Mostly because the built-in features are almost impossible to enable unless you've bought a corporate laptop or desktop that already has all the required components in it. Secondly, because government controlled backdoors are not fantasy:
Open-source encryption software can be easily reviewed for any such backdoors whereas closed-source firmware based solutions can hold nasty surprises in them.
I do agree encrypting in the OS onto an SSD is bad practise. It ain't ethical to target the controllers.There is a lot that goes into this & there could be some undisclosed SF compatibility issues with the hardware manufacturerers
Originally Posted by ObiWan
If you use a program installed on /boot to hash check /boot you are no better off.
Originally Posted by Luke
You really need to keep /boot on a USB drive that you always keep with you and boot from that.
Also, a keylogger could be installed into the BIOS or EFI firmware so you need Secure Boot and a TPM to prevent firmware modifications.
And none of that protects against low tech but effective key logger attacks like putting something slightly sticky and UV glowy on the case so you get it on your fingers and then type on the keys. Then they've got your likely passphrase when they bust in and confiscate everything.
You just can't be too paranoid! :-)
Originally Posted by Zan Lynx
Well, you CAN be so paranoid you assume no defense is possible, so you use none and get on Facebook with Windows and hope the cops raid someone else. Short of that, you structure your setup to put as little trust in your hardware and the environment around it as is necesary to operate it. I've already had one encrypted machine taken in a raid beat attempts by the cops to get into it, I must be doing something right.
Whenever there is a hardware you buy vs open source software choice to be made, go with the software every time. This reduces the number or possible hardware-based attack vectors and increases the odds that your opponent can't get in because the controller of that backdoor can't admit to having it. That last consideration does NOT apply to "Top Secret" but applies to all lower classifications of data.
A TPM is hardware-and a lot more likely the NSA and "Trusted Computing Group" would admit to a backdoor in a TPM in a courtroom than that a motherboard maker would be willing to admit to keylogging all their customers so the FBI can get video of, say, protesters storming a fur shop.
Since /boot is considered easily compromised, a hash check after booting with a program living on encrypted / makes the attack much more difficult, though not impossible. You detect the attack, you change the pasphrase and re-image the OS. Anyone setting up a raid, BTW, will greatly fear the
detection of this sort of preparation, as this means staging a raid where the attackers are expected.
The flash drive approach is good, used it myself in some highly untrusted environments, but it does not protect against the "evil cook" BIOS reflash. Neither does my hash check, but to attack the BIOS requires one visit to determine the board in use, another to change the BIOS, then the harvest raid.
Obviously the ROOM in which a machine is used is an attack vector, a camera is more reliable than glowing UV dust likely to get on every key. Public places, idenify cameras and sit where they can't see the screen. Home and offices, "sweep" the areas from which the keyboard can be seen for cameras. Consider all "smartphones" etc to be malicious, don't let them watch you boot!
One more thing: when they can't get into an encrypted machine, they might offer to give it back. That should ALWAYS be considered malicious, harboring at least a keylogging BIOS. Take it so they can't keep working on it, then SMASH it and throw it in the dumpster.
Last edited by Luke; 05-22-2013 at 01:32 AM.